llvm-svn: 134048

This function has to deal with a lot of special cases, and the old
version got it wrong sometimes. In particular, it would sometimes leave
multiple uses in the stack interval in a single block. That causes bad
code with multiple reloads in the same basic block.

The new version handles block entry and exit in a single pass. It first
eliminates all the easy cases, and then goes on to create a local
interval for the blocks with difficult interference. Previously, we
would only create the local interval for completely isolated blocks.

It can happen that the stack interval becomes completely empty because
we could allocate a register in all edge bundles, and the new local
intervals deal with the interference. The empty stack interval is
harmless, but we need to remove a SplitKit assertion that checks for
empty intervals.

llvm-svn: 134047

llvm-svn: 134036

llvm-svn: 134033

llvm-svn: 134031

llvm-svn: 134030

llvm-svn: 134027

llvm-svn: 134026

llvm-svn: 134024

sink them into MC layer.
- Added MCInstrInfo, which captures the tablegen generated static data. Chang
TargetInstrInfo so it's based off MCInstrInfo.

llvm-svn: 134021

Drop the FpMov instructions, use plain COPY instead.

Drop the FpSET/GET instruction for accessing fixed stack positions.
Instead use normal COPY to/from ST registers around inline assembly, and
provide a single new FpPOP_RETVAL instruction that can access the return
value(s) from a call. This is still necessary since you cannot tell from
the CALL instruction alone if it returns anything on the FP stack. Teach
fast isel to use this.

This provides a much more robust way of handling fixed stack registers -
we can tolerate arbitrary FP stack instructions inserted around calls
and inline assembly. Live range splitting could sometimes break x87 code
by inserting spill code in unfortunate places.

As a bonus we handle floating point inline assembly correctly now.

llvm-svn: 134018

character in std::string was causing failures for a few ObjC and Obj-C++ tests
when -flto was enabled.  Revision 133999 resolved this issue. Thanks Jay!
rdar://9685235
PR10210

llvm-svn: 134017

llvm-svn: 134014

llvm-svn: 134013

llvm-svn: 134010

llvm-svn: 134008

llvm-svn: 134005

avoid getting embedded trailing null bytes in std::strings.

llvm-svn: 133999

llvm-svn: 133998

Also and add a test for popping dead return values and avoid testing the
spill precision.

llvm-svn: 133997

llvm-svn: 133996

llvm-svn: 133995

llvm-svn: 133992

llvm-svn: 133991

llvm-svn: 133990

llvm-svn: 133989

llvm-svn: 133988

evaluates all other IV exprs.

llvm-svn: 133982

llvm-svn: 133981

opening single quote with no closing single quote, and with {} quotes
"inside" of it. This broke some of our tools that scrape test cases.

Also, while here, make the test actually assert what the comment says it
asserts. This was essentially authored by Nick Lewycky, and merely typed
in by myself. Let me know if this is still missing the mark, but the
previous test only succeeded due to the improper quoting preventing
*anything* from matching the grep -- it had a '4(%...)' sequence in the
output!

llvm-svn: 133980

llvm-svn: 133979

llvm-svn: 133978

When the destination operand is the same as the first source register
operand for arithmetic instructions, the destination operand may be omitted.

For example, the following two instructions are equivalent:
and r1, #ff
and r1, r1, #ff

rdar://9672867

llvm-svn: 133973

llvm-svn: 133967

Correctly parse the forms of the Thumb mov-immediate instruction:
  1. 8-bit immediate 0-255.
  2. 12-bit shifted-immediate.

The 16-bit immediate "movw" form is also legal with just a "mov" mnemonic,
but is not yet supported. More parser logic necessary there due to fixups.

llvm-svn: 133966

llvm-svn: 133964

llvm-svn: 133962

a bit more control over the order SCEVs are evaluated.

llvm-svn: 133959

This was causing compile-time failures for some of the Objc and Obj-C++
benchmarks.  The specific errors were of the form: "ld: duplicate symbol …"
rdar://9660124

llvm-svn: 133955

During bottom up fast-isel, instructions emitted to materalize registers are at top of basic block and do not have debug location. This may misguide debugger while entering the basic block and sometimes debugger provides semi useful view of current location to developer by picking up previous known location as current location. Assign a sensible location to the first instruction in a basic block, if it does not have one location derived from source file, so that debugger can provide meaningful user experience to developers in edge cases.

llvm-svn: 133953