specified.

llvm-svn: 104066

8-bit immediate field rather than one with a wider immediate field.

llvm-svn: 104064

The register use operands (e.g. the first argument is passed in a 
register) is currently being modeled as a normal register use,
instead of correctly being an implicit use.  This causes the operand
to get propagated onto the mcinst, which was causing the encoder to
emit a rex prefix byte, which generates an invalid call.

This fixes rdar://7998435

llvm-svn: 104062

Sink dag combine's post index load / store code that swap base ptr and index into the target hook. Only the target knows whether the swap is safe. In Thumb2 mode, the offset must be an immediate. rdar://7998649

llvm-svn: 104060

  X86::ADC32ri $0, %eax
to
  X86::ADC32i32 $0

llvm-svn: 104030

too large limit.

The function would return immediately when finding an addrmode 3/5 instruction.
It needs to keep scanning in case there is an addrmode 6 instruction which drops
the limit to 0.

A test case is very difficult to produce because it will only fail when the
scavenger is used.

rdar://problem/7894847

llvm-svn: 103995

- Change the logic DisableFramePointerElim() to check for the
  -disable-non-leaf-fp-elim before -disable-fp-elim.

llvm-svn: 103990

llvm-svn: 103982

 - Of questionable utility, since in general anything which wants to do this should probably be within a target specific hook, which can rely on the sections being of the appropriate type. However, it can be useful for short term hacks.

llvm-svn: 103980

llvm-svn: 103974

Obvious in retrospect but not fun to debug.

llvm-svn: 103969

Using NEON load / store multiple instructions will no longer create gobs of vmov of D registers!

llvm-svn: 103960

llvm-svn: 103917

<1xi64> -> i64 to work in MMX registers on hosts where -no-sse
is the default (not mine).  The right thing is
to accept this and make i64->f64 conversions go through memory,
but I don't have time right now.

llvm-svn: 103914

(This worked as of about 6 months ago and I didn't track down
exactly what broke it; I think this fix is appropriate.)

llvm-svn: 103911

llvm-svn: 103903

Patch by Charles Davis and Steven Watanabe!

llvm-svn: 103902

llvm-svn: 103901

llvm-svn: 103898

The implementation in LegalizeIntegerTypes to handle this as 
sint64->float + appropriate power of 2 is subject to double rounding,
considered incorrect by numerics people.  Use this implementation only
when it is safe.  This leads to using library calls in some cases
that produced inline code before, but it's correct now.
(EVTToAPFloatSemantics belongs somewhere else, any suggestions?)

Add a correctly rounding (though not particularly fast) conversion
that uses X87 80-bit computations for x86-32.

7885399, 5901940.  This shows up in gcc.c-torture/execute/ieee/rbug.c
in the gcc testsuite on some platforms.

llvm-svn: 103883

This can be extended later on to handle more "complex" constants.

llvm-svn: 103881

Temporary emit it as raw bytes until it will be added to binutils as well.

llvm-svn: 103878

llvm-svn: 103868

llvm-svn: 103855

allow target to override it in order to map register classes to illegal
but synthesizable types. e.g. v4i64, v8i64 for ARM / NEON.

llvm-svn: 103854

llvm-svn: 103851

instructions.

e.g.
%reg1026<def> = VLDMQ %reg1025<kill>, 260, pred:14, pred:%reg0
%reg1027<def> = EXTRACT_SUBREG %reg1026, 6
%reg1028<def> = EXTRACT_SUBREG %reg1026<kill>, 5
...
%reg1029<def> = REG_SEQUENCE %reg1028<kill>, 5, %reg1027<kill>, 6, %reg1028, 7, %reg1027, 8, %reg1028, 9, %reg1027, 10, %reg1030<kill>, 11, %reg1032<kill>, 12

After REG_SEQUENCE is eliminated, we are left with:

%reg1026<def> = VLDMQ %reg1025<kill>, 260, pred:14, pred:%reg0
%reg1029:6<def> = EXTRACT_SUBREG %reg1026, 6
%reg1029:5<def> = EXTRACT_SUBREG %reg1026<kill>, 5

The regular coalescer will not be able to coalesce reg1026 and reg1029 because it doesn't
know how to combine sub-register indices 5 and 6. Now 2-address pass will consult the
target whether sub-registers 5 and 6 of reg1026 can be combined to into a larger
sub-register (or combined to be reg1026 itself as is the case here). If it is possible, 
it will be able to replace references of reg1026 with reg1029 + the larger sub-register
index.

llvm-svn: 103835

llvm-svn: 103833

replace the check with the appropriate predicate. Modify the testcase to reflect
the correct code. (It should be saving callee-saved registers on the stack
allocated by the calling fuction.)

llvm-svn: 103829

llvm-svn: 103826

of "has calls". That's probably wrong, but it needs further
investigation. Revert to the original behavior until this is settled.

llvm-svn: 103824

stack.

llvm-svn: 103813

llvm-svn: 103808

llvm-svn: 103804

the variable actually tracks.

N.B., several back-ends are using "HasCalls" as being synonymous for something
that adjusts the stack. This isn't 100% correct and should be looked into.

llvm-svn: 103802

used more than once. If ISel had put a kill flag on one of them,
it's not valid to transfer the kill flag to each new instance.

llvm-svn: 103799

argument, like "int $4", to not get an Assertion error.

llvm-svn: 103791

llvm-svn: 103790

llvm-svn: 103778

control barriers, not memory ordering barriers.

llvm-svn: 103777