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

Remove code that prevented lowering shuffles if they are used by load and themselves used by a extract_vector_elt. This was done to allow the DAG combiner to collapse to a single element load. Unfortunately, sometimes the extract_vector_elt would disappear before DAG combine could do the transformation leaving a vector_shuffle that isel couldn't handle. New code lets the shuffle be converted to a target specific node, but then adds a combine routine that can convert target specific nodes back to vector_shuffles if the folding criteria are met.

llvm-svn: 153080

Factor out target shuffle mask decoding from getShuffleScalarElt and use a SmallVector of int instead of unsigned for shuffle mask in decode functions. Preparation for another change.

llvm-svn: 153079

When combining (vextract shuffle (load ), <1,u,u,u>), 0) -> (load ), add users of the final load to the worklist too. Needed by changes I'm preparing to make to X86 backend.

llvm-svn: 153078

a variable. The previous code would break the debug info changing
code invariant. This will regress debug info for arguments where
we elide the alloca created.

Fixes rdar://11066468

llvm-svn: 153074

llvm-svn: 153073

llvm-svn: 153072

llvm-svn: 153071

llvm-svn: 153064

llvm-svn: 153063

rdar://11059157

llvm-svn: 153055

rdar://11057160

llvm-svn: 153053

llvm-svn: 153051

Also add some documentation.

llvm-svn: 153050

Patch by Weiming Zhao!
This fixes PR12212

llvm-svn: 153049

instructions have been scheduled. Handy for tracking down scheduler bugs, or
bugs exposed by scheduling.

llvm-svn: 153045

[asan] don't emit __asan_mapping_offset/__asan_mapping_scale by default -- they are currently used only for experiments

llvm-svn: 153040

llvm-svn: 153035

X86InstrCompiler.td.
 
It also adds –mcpu-generic to the legalize-shift-64.ll test so the test
will pass if run on an Intel Atom CPU, which would otherwise
produce an instruction schedule which differs from that which the test expects.

llvm-svn: 153033

llvm-svn: 153031

overflow checking multiply intrinsic as well.

Add a test for this, updating the test from grep to FileCheck.

llvm-svn: 153028

llvm-svn: 153027

llvm-svn: 152999

Reorder includes in Target backends to following coding standards. Remove some superfluous forward declarations.

llvm-svn: 152997

This is particularly helpful as both arguments tend to be constants.

llvm-svn: 152991

llvm-svn: 152981

llvm-svn: 152980

Pass TargetOptions to HexagonTargetMachine constructor by reference to match other targets and the base class.

llvm-svn: 152979

llvm-svn: 152978

 evaluated to '1' when the argument list was empty (should be '0').

rdar://11057257

llvm-svn: 152967

fast-isel before emitting code. If the program bails after code was emitted,
then it could lead to the stack being adjusted more than once (two
CALLSEQ_BEGINs emitted) but being adjuste back only once after the call. This
leads to general badness and gnashing of teeth.
<rdar://problem/11050630>

llvm-svn: 152959

rdar://11065671

llvm-svn: 152954

llvm-svn: 152946

It's not a good style idea, as the registers will be laid down in memory in
numerical order, not the order they're in the list, but it's legal. vldm/vstm
are stricter.

rdar://11064740

llvm-svn: 152943

llvm-svn: 152935

ScheduleDAGInstrs: When adding uses we add them into a set that's empty at the beginning, no need to maintain another set for the added regs.

llvm-svn: 152934

Saves one machine word on MachineInstr (88->80 bytes on x86_64, 48->44 on i386).

llvm-svn: 152930

No functionality change.

llvm-svn: 152927

alignment. If that's the case, then we want to make sure that we don't increase
the alignment of the store instruction. Because if we increase it to be "more
aligned" than the pointer, code-gen may use instructions which require a greater
alignment than the pointer guarantees.
<rdar://problem/11043589>

llvm-svn: 152907

It was added in 2007 as the first cut at supporting no-inline
attributes, but we didn't have function attributes of any form at the
time. However, it was added without any mention in the LangRef or other
documentation.

Later on, in 2008, Devang added function notes for 'inline=never' and
then turned them into proper function attributes. From that point
onward, as far as I can tell, the world moved on, and no one has touched
'llvm.noinline' in any meaningful way since.

It's time has now come. We have had better mechanisms for doing this for
a long time, all the frontends I'm aware of use them, and this is just
holding back progress. Given that it was never a documented feature of
the IR, I've provided no auto-upgrade support. If people know of real,
in-the-wild bitcode that relies on this, yell at me and I'll add it, but
I *seriously* doubt anyone cares.

llvm-svn: 152904