have to be registers, per gcc documentation.  This affects
the logic for determining what "g" should lower to.  PR 7393.
A couple of existing testcases are affected.

llvm-svn: 107079

llvm-svn: 107065

llvm-svn: 107060

you would expect.

Don't assert on that case, just give up.

This fixes PR7513.

llvm-svn: 107046

When an instruction has tied operands and physreg defines, we must take extra
care that the tied operands conflict with neither physreg defs nor uses.

The special treatment is given to inline asm and instructions with tied operands
/ early clobbers and physreg defines.

This fixes PR7509.

llvm-svn: 107043

Radar 8122864.

llvm-svn: 107027

llvm-svn: 107014

block, not...", it caused a bunch of nightly test regressions.

llvm-svn: 107009

llvm-svn: 106990

This produces terrible but correct code.

llvm-svn: 106952

regressions.

--- Reverse-merging r106939 into '.':
U    test/CodeGen/Thumb2/thumb2-ifcvt3.ll
U    lib/CodeGen/IfConversion.cpp

llvm-svn: 106951

llvm-svn: 106943

if-conversion.  The RemoveExtraEdges function doesn't work for blocks that
end with unanalyzable branches, so in those cases, the "extra" edges must
be explicitly removed.  The CopyAndPredicateBlock and MergeBlocks methods
can also avoid copying successor edges due to branches that have already
been removed.  The latter case is especially helpful when MergeBlocks is
called for handling "diamond" if-conversions, where otherwise you can end
up with some weird intermediate states in the CFG.  Unfortunately I've
been unable to find cases where this cleanup actually makes a significant
difference in the code.  There is one test where we manage to remove an
empty block at the end of a function.  Radar 6911268.

llvm-svn: 106939

just at the head, when doing diamond if-conversion. rdar://7797940

llvm-svn: 106907

The VNInfo.kills vector was almost unused except for all the code keeping it
updated. The few places using it were easily rewritten to check for interval
ends instead.

The two new methods LiveInterval::killedAt and killedInRange are replacements.

This brings us down to 3 independent data structures tracking kills.

llvm-svn: 106905

llvm-svn: 106901

llvm-svn: 106895

llvm-svn: 106894

for an "i" constraint should get lowered; PR 6309.  While
this argument was passed around a lot, this is the only
place it was used, so it goes away from a lot of other
places.

llvm-svn: 106893

- 2010-06-25-CoalescerSubRegDefDead.ll is the testcase for r106878.

llvm-svn: 106880

are dead, not just the def of this register. I.e., a register could be dead, but
it's subreg isn't.

Testcase to follow with a subsequent patch.

llvm-svn: 106878

llvm-svn: 106865

is not used.  Spotted by gcc-4.6.

llvm-svn: 106854

and CallInst for getting hold
of the intrinsic's arguments

simplify along the way (at least for me this is much more legible now)
Bill, Baldrick or Anton, please review\!

llvm-svn: 106838

llvm-svn: 106837

llvm-svn: 106836

llvm-svn: 106835

llvm-svn: 106833

llvm-svn: 106829

llvm-svn: 106828

llvm-svn: 106827

is reused as an input.  PR 4118.  Testcase is too big,
as usual with bugs in this area, but there's one in
the PR.

llvm-svn: 106816

This fixes PR7479 and PR7485. The test cases from those PRs are big, so not
included. However, PR7485 comes from self hosting on FreeBSD, so we will surely
hear about any regression.

llvm-svn: 106811

llvm-svn: 106809

and to clean up unused incoming physregs from the live-in list.

llvm-svn: 106805

original SDNode. This is badness. Also, this function allows one SDNode to point
multiple flags to another SDNode. Badness as well.

llvm-svn: 106793

DBG_VALUE machine instruction pointing to undefined register for a variable justify a separate scope if the variable is inlined function's argument.
Radar 8122864.

llvm-svn: 106792

vector instead. This avoids needless copying and allocation.

Add documentation.

llvm-svn: 106788

This method was always a bit too simplistic for the real world. It didn't really
deal with subregisters and such.

llvm-svn: 106781

llvm-svn: 106780