valid comments in inline assembly.
gcc.target/i386/20011009-1.c

llvm-svn: 57365

and APFloat::convertToInteger.  Restore return value to
IEEE754.  Adjust all users accordingly.

llvm-svn: 57329

make it clearer what the function does.  No functional
change.

llvm-svn: 57325

isReg, etc., from isRegister, etc.

llvm-svn: 57006

llvm-svn: 56584

llvm-svn: 56583

llvm-svn: 56579

llvm-svn: 56574

llvm-svn: 56573

llvm-svn: 56572

llvm-svn: 56571

RA problem by expanding the live interval of an
earlyclobber def back one slot.  Remove
overlap-earlyclobber throughout.  Remove 
earlyclobber bits and their handling from
live internals.

llvm-svn: 56539

with an earlyclobber operand elsewhere.  Propagate
this bit and the earlyclobber bit through SDISel.
Change linear-scan RA not to allocate regs in a way 
that conflicts with an earlyclobber.  See also comments.

llvm-svn: 56290

UsedDirective for some symbols in llvm.used into
Darwin-specific code.  I've decided LessPrivateGlobal
is potentially a useful abstraction and left it in
the target-independent area, with improved comment.

llvm-svn: 56024

objects in llvm.used (thanks Anton).  Makes visible
the magic 'l' prefix for symbols on Darwin which are
to be passed through the assembler, then removed at
linktime (previously all references to this had been
hidden in the ObjC FE code, oh well).

llvm-svn: 55973

llvm-svn: 55962

llvm-svn: 55919

llvm-svn: 55779

list that have internal linkage; the linker doesn't need
or want this.  (These objects must still be preserved
at compile time, so just removing them from the llvm.used
list doesn't work.)  Should affect only Darwin.

llvm-svn: 55722

llvm-svn: 55134

llvm-svn: 55092

llvm-svn: 54978

In particular, Collector was confusing to implementors. Several
thought that this compile-time class was the place to implement
their runtime GC heap. Of course, it doesn't even exist at runtime.
Specifically, the renames are:

  Collector               -> GCStrategy
  CollectorMetadata       -> GCFunctionInfo
  CollectorModuleMetadata -> GCModuleInfo
  CollectorRegistry       -> GCRegistry
  Function::getCollector  -> getGC (setGC, hasGC, clearGC)

Several accessors and nested types have also been renamed to be
consistent. These changes should be obvious.

llvm-svn: 54899

llvm-svn: 54891

llvm-svn: 54885

llvm-svn: 54884

Factor GC metadata table assembly generation out of Collector in preparation for splitting AsmPrinter into its own library.

llvm-svn: 54881

Factor GC metadata table assembly generation out of Collector in preparation for splitting AsmPrinter into its own library.

llvm-svn: 54880

returning an std::string by value, it fills in a SmallString/SmallVector
passed in.  This significantly reduces string thrashing in some cases.

More specifically, this:
 - Adds an operator<< and a print method for APInt that allows you to 
   directly send them to an ostream.
 - Reimplements APInt::toString to be much simpler and more efficient
   algorithmically in addition to not thrashing strings quite as much.

This speeds up llvm-dis on kc++ by 7%, and may also slightly speed up the
asmprinter.  This also fixes a bug I introduced into the asmwriter in a
previous patch w.r.t. alias printing.

llvm-svn: 54873

Move SLEB/ULEB size calculation routines from AsmPrinter to TargetAsmInfo. This makes JIT asmprinter-free.

llvm-svn: 54843

llvm-svn: 54540

is narrower than the pointer. This testcase emits:

  .byte (((17) - 16) & 255)

llvm-svn: 54517

llvm-svn: 53316

llvm-svn: 53237

llvm-svn: 53215

llvm-svn: 52992

Add a version of AsmPrinter::EOL that takes a const char* so that we don't have to do as many implicit std::string constructions.
Unfortunately, this doesn't appear to translate to a real speedup in practice.

llvm-svn: 52981

llvm-svn: 52944

llvm-svn: 52929

are the same as in unpacked structs, only field
positions differ.  This only matters for structs
containing x86 long double or an apint; it may
cause backwards compatibility problems if someone
has bitcode containing a packed struct with a
field of one of those types.
The issue is that only 10 bytes are needed to
hold an x86 long double: the store size is 10
bytes, but the ABI size is 12 or 16 bytes (linux/
darwin) which comes from rounding the store size
up by the alignment.  Because it seemed silly not
to pack an x86 long double into 10 bytes in a
packed struct, this is what was done.  I now
think this was a mistake.  Reserving the ABI size
for an x86 long double field even in a packed
struct makes things more uniform: the ABI size is
now always used when reserving space for a type.
This means that developers are less likely to
make mistakes.  It also makes life easier for the
CBE which otherwise could not represent all LLVM
packed structs (PR2402).
Front-end people might need to adjust the way
they create LLVM structs - see following change
to llvm-gcc.

llvm-svn: 51928