llvm-svn: 129612

Fix lines that have incorrect indentation or exceed 80 columns. There is no change in functionality.

llvm-svn: 129606

llvm-svn: 108366

Default HasSetDirective to true, since most targets have it.

The targets that claim to not have it probably do, or it is
spelled differently. These include Blackfin, Mips, Alpha, and
PIC16.  All of these except pic16 are normal ELF targets, so
they almost certainly have it.

llvm-svn: 94585

make it clear what it is, instead of how it is used.

llvm-svn: 94448

llvm-svn: 94411

stomache MCAsmInfo having this, and I found a better solution to
this layering issue.

llvm-svn: 93985

I really want clients of the streamer to be able to say "emit this
64-bit integer" and have it get broken down right by the streamer.

I may change this in the future, we'll see how it works out.

llvm-svn: 93934

llvm-svn: 79779

llvm-svn: 79763

pair instead of from a virtual method on TargetMachine.  This cuts the final
ties of TargetAsmInfo to TargetMachine, meaning that MC can now use 
TargetAsmInfo.

llvm-svn: 78802

no longer needs a targetmachine to initialize itself.

llvm-svn: 78710

version.  This allows TAI implementations to specify the directive to use
based on the mode being codegen'd for.

The real fix for this is to remove JumpTableDirective, but I don't feel
like diving into the jumptable snarl just now.

llvm-svn: 78709

options, which don't appear to be useful.  -enable-mips-absolute-call is
completely unused (and unless I'm mistaken, is supposed to have the 
same effect that -relocation-model=dynamic-no-pic should have), 
and -disable-mips-abicall appears to be effectively a 
synonym for -relocation-model=static. Adjust the few users of hasABICall
to checks which seem more appropriate.  Update MipsSubtarget, 
MipsTargetMachine, and MipselTargetMachine to synchronize with recent 
changes.

llvm-svn: 77938

no longer depends on TM!

llvm-svn: 77863

llvm-svn: 77827

llvm-svn: 77820

it is highly specific to the object file that will be generated in the end,
this introduces a new TargetLoweringObjectFile interface that is implemented
for each of ELF/MachO/COFF/Alpha/PIC16 and XCore.

Though still is still a brutal and ugly refactoring, this is a major step
towards goodness.

This patch also:
1. fixes a bunch of dangling pointer problems in the PIC16 backend.
2. disables the TargetLowering copy ctor which PIC16 was accidentally using.
3. gets us closer to xcore having its own crazy target section flags and
   pic16 not having to shadow sections with its own objects.
4. fixes wierdness where ELF targets would set CStringSection but not
   CStringSection_.  Factor the code better.
5. fixes some bugs in string lowering on ELF targets.

llvm-svn: 77294

instead.

llvm-svn: 77186

instead and drive things based off of that.

llvm-svn: 77184

'unnamed' bss section, but some impls would want a named one.  Since
they don't have consistent behavior, just make each target do their
own thing, instead of doing something "sortof common" then having
targets change immutable objects later.

llvm-svn: 77165

llvm-svn: 76937

a sad mistake that is regretted. :)

llvm-svn: 76935

a better solution for it in the future.

llvm-svn: 76818

will make it more obvious what it represents, and stop
it being confused with the StoreSize.

llvm-svn: 71349

and extern_weak_odr.  These are the same as the non-odr versions,
except that they indicate that the global will only be overridden
by an *equivalent* global.  In C, a function with weak linkage can
be overridden by a function which behaves completely differently.
This means that IP passes have to skip weak functions, since any
deductions made from the function definition might be wrong, since
the definition could be replaced by something completely different
at link time.   This is not allowed in C++, thanks to the ODR
(One-Definition-Rule): if a function is replaced by another at
link-time, then the new function must be the same as the original
function.  If a language knows that a function or other global can
only be overridden by an equivalent global, it can give it the
weak_odr linkage type, and the optimizers will understand that it
is alright to make deductions based on the function body.  The
code generators on the other hand map weak and weak_odr linkage
to the same thing.

llvm-svn: 66339

suggested by Chris.

llvm-svn: 62099

adding a TargetMachine member to the base TargetAsmInfo class instead.

llvm-svn: 58624

instead of hasWeakLinkage in a bunch of optimization
passes.

llvm-svn: 56782

llvm-svn: 56582

llvm-svn: 56580

llvm-svn: 54534

It's not legal to output a GV in a coalesced section if it's used in an ARM PIC relative constantpool.

llvm-svn: 54519

llvm-svn: 54451

llvm-svn: 54350

llvm-svn: 54214

Fixed COMM asm directive usage.
ConstantPool using custom FourByteConstantSection.

llvm-svn: 54139

Added ConstantPool support.

llvm-svn: 53951

llvm-svn: 53912

Fixed small bug.

llvm-svn: 53908