i128). In that case, we may not be able to print out the MCExpr as an
expression. For instance, we could have an MCExpr like this:

    0xBEEF0000BEEF0000 | (0xBEEF0000BEEF0000 << 64)

The MCExpr printer handles sizes up to 64-bits, but this expression would
require 128-bits. In this situation, try to evaluate the constant expression and
emit that as the value into 64-bit chunks.
<rdar://problem/11070338>

llvm-svn: 153081

llvm-svn: 152153

llvm-svn: 152016

The standard function epilog includes a .size directive, but ppc64 uses
an alternate local symbol to tag the actual start of each function.

Until recently, binutils accepted the .size directive as:
 .size	test1, .Ltmp0-test1
however, using this directive with recent binutils will result in the error:
 .size expression for XXX does not evaluate to a constant
so we must use the label which actually tags the start of the function.

llvm-svn: 151200

method. This allows the target lowering code to not have to deal with MDNodes.

Also, avoid leaking memory like a sieve by not creating a global variable for
the image info section, but just emitting the code directly.

llvm-svn: 150624

The MachO back-end needs to emit the garbage collection flags specified in the
module flags. This is a WIP, so the front-end hasn't been modified to emit these
flags just yet. Documentation and front-end switching to occur soon.

llvm-svn: 150507

but with a critical fix to the SelectionDAG code that optimizes copies
from strings into immediate stores: the previous code was stopping reading
string data at the first nul.  Address this by adding a new argument to
llvm::getConstantStringInfo, preserving the behavior before the patch.

llvm-svn: 149800

needed to emit a 64-bit gp-relative relocation entry. Make changes necessary
for emitting jump tables which have entries with directive .gpdword. This patch
does not implement the parts needed for direct object emission or JIT.

llvm-svn: 149668

These are:

r149348
r149351
r149352
r149354
r149356
r149357
r149361
r149362
r149364
r149365

llvm-svn: 149470

with recent changes, ConstantArray is never a "string".  Remove the associated
methods and constant fold the clients to false.

llvm-svn: 149362

CodeGen/X86/global-sections.ll to fail with CDArray

llvm-svn: 149343

vectors of all one bits to be printed more cleverly in the AsmPrinter.
Unfortunately, the byte value for all one bits is the same with
-fsigned-char as the error return of '-1'. Force this to be the unsigned
byte value when returning it to avoid this problem, and update the test
case for the shiny new behavior.

Yay for building LLVM and Clang with -funsigned-char.

Chris, please review, and let me know if there is any reason to not
desire this change. It seems good on the surface, and certainly intended
based on the code written.

llvm-svn: 149299

like normal integers.

llvm-svn: 149223

llvm-svn: 149222

Add support for the R_ARM_TARGET1 relocation, which should be given to relocations applied to all C++ constructors and destructors.

This enables the linker to match concrete relocation types (absolute or relative) with whatever library or C++ support code is being linked against.

llvm-svn: 149057

and let linker handle the rest.

This finally fixes PR5329

llvm-svn: 148990

llvm-svn: 148897

and clean up some other misc stuff.  Unlike ConstantArray, we will
prefer to emit .fill directives for "String" arrays that all have
the same value, since they are denser than emitting a .ascii

llvm-svn: 148793

llvm-svn: 148578

llvm-svn: 148065

The registers are placed into the saved registers list in the reverse order,
which is why the original loop was written to loop backwards.

llvm-svn: 148064

llvm-svn: 146927

generator to it. For non-bundle instructions, these behave exactly the same
as the MC layer API.

For properties like mayLoad / mayStore, look into the bundle and if any of the
bundled instructions has the property it would return true.
For properties like isPredicable, only return true if *all* of the bundled
instructions have the property.
For properties like canFoldAsLoad, isCompare, conservatively return false for
bundles.

llvm-svn: 146026

llvm-svn: 146001

This was actually a bit of a mess. TLI.setPrefLoopAlignment was clearly
documented as taking log2(bytes) units, but the x86 target would still
set a preferred loop alignment of '16'.

CodePlacementOpt passed this number on to the basic block, and
AsmPrinter interpreted it as bytes.

Now both MachineFunction and MachineBasicBlock use logarithmic
alignments.

Obviously, MachineConstantPool still measures alignments in bytes, so we
can emulate the thrill of using as.

llvm-svn: 145889

Maybe some targets should use this as well.

Patch by Evgeniy Stepanov!

llvm-svn: 145781

has a reference to it. Unfortunately, that doesn't work for codegen passes
since we don't get notified of MBB's being deleted (the original BB stays).

Use that fact to our advantage and after printing a function, check if
any of the IL BBs corresponds to a symbol that was not printed. This fixes
pr11202.

llvm-svn: 144674

llvm-svn: 143799

llvm-svn: 143097

Teach the MC to output code/data region marker labels in MachO and ELF modes.  These are used by disassemblers to provide better disassembly, particularly on targets like ARM Thumb that like to intermingle data in the TEXT segment.

llvm-svn: 141135

llvm-svn: 140784

llvm-svn: 139015

- On COFF the .lcomm directive has an alignment argument.
- On ELF we fall back to .local + .comm

Based on a patch by NAKAMURA Takumi.

Fixes PR9337, PR9483 and PR10128.

llvm-svn: 138976

Stores sizes as uint64_t to avoid possible truncation.

llvm-svn: 138901

Emit a repeated sequence of bytes using .zero.  This saves an enormous
amount of asm file space for certain programs.

llvm-svn: 138864

when outputting them.  With this, the entire LLVM testsuite
passes when built with dragonegg.

llvm-svn: 138724

llvm-svn: 136609

There is still a bit more refactoring left to do in Targets. But we are now very
close to fixing all the layering issues in MC.

llvm-svn: 135611

llvm-svn: 135478

llvm-svn: 135450