Commit Graph

12632 Commits

Author SHA1 Message Date
Dan Gohman
bf923b815d Reapply r143177 and r143179 (reverting r143188), with scheduler
fixes: Use a separate register, instead of SP, as the
calling-convention resource, to avoid spurious conflicts with
actual uses of SP. Also, fix unscheduling of calling sequences,
which can be triggered by pseudo-two-address dependencies.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143206 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-28 17:55:38 +00:00
NAKAMURA Takumi
c3e48c38bf Dwarf: [PR11022] Fix emitting DW_AT_const_value(>i64), to be host-endian-neutral.
Don't assume APInt::getRawData() would hold target-aware endianness nor host-compliant endianness. rawdata[0] holds most lower i64, even on big endian host.

FIXME: Add a testcase for big endian target.

FIXME: Ditto on CompileUnit::addConstantFPValue() ?

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143194 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-28 14:12:22 +00:00
Benjamin Kramer
91bbe23716 Use BranchProbability compare operators.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143190 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-28 11:14:31 +00:00
Duncan Sands
62c1d00dfd Speculatively disable Dan's commits 143177 and 143179 to see if
it fixes the dragonegg self-host (it looks like gcc is miscompiled).
Original commit messages:
Eliminate LegalizeOps' LegalizedNodes map and have it just call RAUW
on every node as it legalizes them. This makes it easier to use
hasOneUse() heuristics, since unneeded nodes can be removed from the
DAG earlier.

Make LegalizeOps visit the DAG in an operands-last order. It previously
used operands-first, because LegalizeTypes has to go operands-first, and
LegalizeTypes used to be part of LegalizeOps, but they're now split.
The operands-last order is more natural for several legalization tasks.
For example, it allows lowering code for nodes with floating-point or
vector constants to see those constants directly instead of seeing the
lowered form (often constant-pool loads). This makes some things
somewhat more complicated today, though it ought to allow things to be
simpler in the future. It also fixes some bugs exposed by Legalizing
using RAUW aggressively.

Remove the part of LegalizeOps that attempted to patch up invalid chain
operands on libcalls generated by LegalizeTypes, since it doesn't work
with the new LegalizeOps traversal order. Instead, define what
LegalizeTypes is doing to be correct, and transfer the responsibility
of keeping calls from having overlapping calling sequences into the
scheduler.

Teach the scheduler to model callseq_begin/end pairs as having a
physical register definition/use to prevent calls from having
overlapping calling sequences. This is also somewhat complicated, though
there are ways it might be simplified in the future.

This addresses rdar://9816668, rdar://10043614, rdar://8434668, and others.
Please direct high-level questions about this patch to management.

Delete #if 0 code accidentally left in.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143188 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-28 09:55:57 +00:00
Nick Lewycky
6a7efcfc02 Always use the string pool, even when it makes the .o larger. This may help
tools that read the debug info in the .o files by making the DIE sizes more
consistent.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143186 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-28 05:29:47 +00:00
Dan Gohman
3799efab8c Delete #if 0 code accidentally left in.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143179 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-28 01:41:21 +00:00
Dan Gohman
2ba60e5930 Eliminate LegalizeOps' LegalizedNodes map and have it just call RAUW
on every node as it legalizes them. This makes it easier to use
hasOneUse() heuristics, since unneeded nodes can be removed from the
DAG earlier.

Make LegalizeOps visit the DAG in an operands-last order. It previously
used operands-first, because LegalizeTypes has to go operands-first, and
LegalizeTypes used to be part of LegalizeOps, but they're now split.
The operands-last order is more natural for several legalization tasks.
For example, it allows lowering code for nodes with floating-point or
vector constants to see those constants directly instead of seeing the
lowered form (often constant-pool loads). This makes some things
somewhat more complicated today, though it ought to allow things to be
simpler in the future. It also fixes some bugs exposed by Legalizing
using RAUW aggressively.

Remove the part of LegalizeOps that attempted to patch up invalid chain
operands on libcalls generated by LegalizeTypes, since it doesn't work
with the new LegalizeOps traversal order. Instead, define what
LegalizeTypes is doing to be correct, and transfer the responsibility
of keeping calls from having overlapping calling sequences into the
scheduler.

Teach the scheduler to model callseq_begin/end pairs as having a
physical register definition/use to prevent calls from having
overlapping calling sequences. This is also somewhat complicated, though
there are ways it might be simplified in the future.

This addresses rdar://9816668, rdar://10043614, rdar://8434668, and others.
Please direct high-level questions about this patch to management.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143177 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-28 01:29:32 +00:00
Nick Lewycky
390c40d96a Teach our Dwarf emission to use the string pool.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143097 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-27 06:44:11 +00:00
Eli Friedman
fd58cd7563 Don't crash on 128-bit sdiv by constant. Found by inspection.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143095 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-27 02:06:39 +00:00
Lang Hames
15701f8969 Rename NonScalarIntSafe to something more appropriate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143080 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-26 23:50:43 +00:00
Nick Lewycky
746cb670c3 Reflow lines, fix comments for doxygen style, fix whitespace. No functionality
change.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143074 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-26 22:55:33 +00:00
Duncan Sands
a921a46854 Simplify SplitVecRes_UnaryOp by removing all the code that is
trying to legalize the operand types when only the result type
is required to be legalized - the type legalization machinery
will get round to the operands later if they need legalizing.
There can be a point to legalizing operands in parallel with
the result: when this saves compile time or results in better
code.  There was only one case in which this was true: when
the operand is also split, so keep the logic for that bit.
As a result of this change, additional operand legalization
methods may need to be introduced to handle nodes where the
result and operand types can differ, like SIGN_EXTEND, but
the testsuite doesn't contain any tests where this is the case.
In any case, it seems better to require such methods (and die
with an assert if they doesn't exist) than to quietly produce
wrong code if we forgot to special case the node in
SplitVecRes_UnaryOp.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143026 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-26 14:11:18 +00:00
Jakob Stoklund Olesen
794439183a Don't use floating point to do an integer's job.
This code makes different decisions when compiled into x87 instructions
because of different rounding behavior.  That caused phase 2/3
miscompares on 32-bit Linux when the phase 1 compiler was built with gcc
(using x87), and the phase 2 compiler was built with clang (using SSE).

This fixes PR11200.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143006 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-26 01:47:48 +00:00
Evan Cheng
73b5bb3865 Disable LICM speculation in high register pressure situation again now that Devang has fixed other issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143003 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-26 01:26:57 +00:00
Bill Wendling
a823e3d42c Reapply r142920 with fix:
An MBB which branches to an EH landing pad shouldn't be considered for tail merging.

In SjLj EH, the jump to the landing pad is not done explicitly through a branch
statement. The EH landing pad is added as a successor to the throwing
BB. Because of that however, the branch folding pass could mistakenly think that
it could merge the throwing BB with another BB. This isn't safe to do.
<rdar://problem/10334833>


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143001 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-26 01:10:25 +00:00
Eli Friedman
9312613137 Remove a couple redundant checks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142959 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-25 20:34:22 +00:00
Jim Grosbach
ca30f75703 Make assert() message more informative.
PR11217.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142956 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-25 20:30:48 +00:00
Duncan Sands
51583ce4b6 Revert commit 142891. Takumi bisected the tablegen miscompiles
down to this commit.  Original commit message:

An MBB which branches to an EH landing pad shouldn't be considered for tail merging.

In SjLj EH, the jump to the landing pad is not done explicitly through a branch
statement. The EH landing pad is added as a successor to the throwing
BB. Because of that however, the branch folding pass could mistakenly think that
it could merge the throwing BB with another BB. This isn't safe to do.
<rdar://problem/10334833>



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142920 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-25 12:30:22 +00:00
Nick Lewycky
000b9bdd33 Remove dead enum value. There is no DIESectionOffset.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142912 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-25 07:05:26 +00:00
Eric Christopher
fd747b24a3 Remove unused forward decl.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142892 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-25 00:55:35 +00:00
Bill Wendling
86ed4089e3 An MBB which branches to an EH landing pad shouldn't be considered for tail merging.
In SjLj EH, the jump to the landing pad is not done explicitly through a branch
statement. The EH landing pad is added as a successor to the throwing
BB. Because of that however, the branch folding pass could mistakenly think that
it could merge the throwing BB with another BB. This isn't safe to do.
<rdar://problem/10334833>


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142891 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-25 00:54:05 +00:00
Bill Wendling
671215464c Check the visibility of the global variable before placing it into the stubs
table. A hidden variable could potentially end up in both lists.
<rdar://problem/10336715>


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142869 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-24 23:05:43 +00:00
Douglas Gregor
88d734de43 Really unbreak CMake build
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142822 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-24 18:10:52 +00:00
Douglas Gregor
91336cde45 Unbreak CMake build
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142821 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-24 18:09:23 +00:00
Dan Gohman
83dae4466e Delete the top-down "Latency" scheduler. Top-down scheduling doesn't handle
physreg dependencies, and upcoming codegen changes will require proper
physreg dependence handling.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142816 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-24 18:01:06 +00:00
Dan Gohman
d5333d6922 Delete the Latency scheduling preference.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142815 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-24 17:56:48 +00:00
Dan Gohman
692c1d8535 Change this overloaded use of Sched::Latency to be an overloaded
use of Sched::ILP instead, as Sched::Latency is going away.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142813 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-24 17:55:11 +00:00
Dan Gohman
8c2d270ae8 Change the default scheduler from Latency to ILP, since Latency
is going away.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142810 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-24 17:45:02 +00:00
Bill Wendling
d2dae0cfa0 Cleanup. Get rid of the old SjLj EH lowering code. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142800 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-24 17:12:36 +00:00
Chandler Carruth
e4617c04c8 Sink an otherwise unused variable's initializer into the asserts that
used it. Fixes an unused variable warning from GCC on release builds.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142799 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-24 16:51:55 +00:00
Chandler Carruth
66d847c8ff Now that we have comparison on probabilities, add some static functions
to get important constant branch probabilities and use them for finding
the best branch out of a set of possibilities.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142762 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-23 20:10:34 +00:00
Chandler Carruth
4f78053695 Remove a commented out line of code that snuck by my auditing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142761 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-23 20:10:30 +00:00
Chandler Carruth
3071363bcd Completely re-write the algorithm behind MachineBlockPlacement based on
discussions with Andy. Fundamentally, the previous algorithm is both
counter productive on several fronts and prioritizing things which
aren't necessarily the most important: static branch prediction.

The new algorithm uses the existing loop CFG structure information to
walk through the CFG itself to layout blocks. It coalesces adjacent
blocks within the loop where the CFG allows based on the most likely
path taken. Finally, it topologically orders the block chains that have
been formed. This allows it to choose a (mostly) topologically valid
ordering which still priorizes fallthrough within the structural
constraints.

As a final twist in the algorithm, it does violate the CFG when it
discovers a "hot" edge, that is an edge that is more than 4x hotter than
the competing edges in the CFG. These are forcibly merged into
a fallthrough chain.

Future transformations that need te be added are rotation of loop exit
conditions to be fallthrough, and better isolation of cold block chains.
I'm also planning on adding statistics to model how well the algorithm
does at laying out blocks based on the probabilities it receives.

The old tests mostly still pass, and I have some new tests to add, but
the nested loops are still behaving very strangely. This almost seems
like working-as-intended as it rotated the exit branch to be
fallthrough, but I'm not convinced this is actually the best layout. It
is well supported by the probabilities for loops we currently get, but
those are pretty broken for nested loops, so this may change later.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142743 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-23 09:18:45 +00:00
Bill Wendling
0ad56122e5 Make sure that the landing pads themselves have no PHI instructions in them.
The assumption in the back-end is that PHIs are not allowed at the start of the
landing pad block for SjLj exceptions.
<rdar://problem/10313708>


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142689 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-21 22:08:56 +00:00
Nadav Rotem
a054bcb4cf Fix pr11194. When promoting and splitting integers we need to use
ZExtPromotedInteger and SExtPromotedInteger based on the operation we legalize.

SetCC return type needs to be legalized via PromoteTargetBoolean.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142660 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-21 17:35:19 +00:00
Nadav Rotem
4bd222ae26 1. Fix the widening of SETCC in WidenVecOp_SETCC. Use the correct return CC type.
2. Fix a typo in CONCAT_VECTORS which exposed the bug in #1.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142648 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-21 11:42:07 +00:00
Chandler Carruth
4a85cc982a Add loop aligning to MachineBlockPlacement based on review discussion so
it's a bit more plausible to use this instead of CodePlacementOpt. The
code for this was shamelessly stolen from CodePlacementOpt, and then
trimmed down a bit. There doesn't seem to be much utility in returning
true/false from this pass as we may or may not have rewritten all of the
blocks. Also, the statistic of counting how many loops were aligned
doesn't seem terribly important so I removed it. If folks would like it
to be included, I'm happy to add it back.

This was probably the most egregious of the missing features, and now
I'm going to start gathering some performance numbers and looking at
specific loop structures that have different layout between the two.

Test is updated to include both basic loop alignment and nested loop
alignment.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142645 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-21 08:57:37 +00:00
Chandler Carruth
db35087d21 Implement a block placement pass based on the branch probability and
block frequency analyses. This differs substantially from the existing
block-placement pass in LLVM:

1) It operates on the Machine-IR in the CodeGen layer. This exposes much
   more (and more precise) information and opportunities. Also, the
   results are more stable due to fewer transforms ocurring after the
   pass runs.
2) It uses the generalized probability and frequency analyses. These can
   model static heuristics, code annotation derived heuristics as well
   as eventual profile loading. By basing the optimization on the
   analysis interface it can work from any (or a combination) of these
   inputs.
3) It uses a more aggressive algorithm, both building chains from tho
   bottom up to maximize benefit, and using an SCC-based walk to layout
   chains of blocks in a profitable ordering without O(N^2) iterations
   which the old pass involves.

The pass is currently gated behind a flag, and not enabled by default
because it still needs to grow some important features. Most notably, it
needs to support loop aligning and careful layout of loop structures
much as done by hand currently in CodePlacementOpt. Once it supports
these, and has sufficient testing and quality tuning, it should replace
both of these passes.

Thanks to Nick Lewycky and Richard Smith for help authoring & debugging
this, and to Jakob, Andy, Eric, Jim, and probably a few others I'm
forgetting for reviewing and answering all my questions. Writing
a backend pass is *sooo* much better now than it used to be. =D

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142641 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-21 06:46:38 +00:00
Chandler Carruth
ec0e5475fd Remove a now dead function, fixing -Wunused-function warnings from
Clang.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142631 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-21 01:23:41 +00:00
Dan Gohman
ff764815e6 Delete the list-tdrr scheduler. Top-down schedulers are going away
because they don't support physical register dependencies.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142620 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-20 21:44:34 +00:00
Chad Rosier
e65177f965 Revert r142579, "Fix a type in the legalization of CONCAT_VECTORS". This is
causing one of the unit tests to infinitely loop, which resulted in the 
buildbots stalling.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142604 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-20 19:19:10 +00:00
Devang Patel
06e16bbec0 As Evan suggested, loads from constant pool are safe to speculate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142593 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-20 17:42:23 +00:00
Devang Patel
e6de9f30cb Add a comment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142592 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-20 17:31:18 +00:00
Nadav Rotem
28e65b5245 Fix a type in the legalization of CONCAT_VECTORS.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142579 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-20 13:38:16 +00:00
Nadav Rotem
815af82b74 Improve code generation for vselect on SSE2:
When checking the availability of instructions using the TLI, a 'promoted'
instruction IS available. It means that the value is bitcasted to another type
for which there is an operation. The correct check for the availablity of an
instruction is to check if it should be expanded.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142542 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-19 20:43:16 +00:00
Nadav Rotem
ca58c72267 Add support for the vector-widening of vselect and vector-setcc
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142488 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-19 09:45:11 +00:00
Nick Lewycky
20b2b788b4 Missed a spot!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142436 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-18 22:40:18 +00:00
Nick Lewycky
024170f859 Fix some typo/formatting issues. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142435 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-18 22:39:43 +00:00
Nadav Rotem
fbf19ef186 Fix a bug in the legalization of vector anyext-load and trunc-store. Mem Index starts with zero.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142434 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-18 22:32:43 +00:00
Bob Wilson
db2b18feba Fix a DAG combiner assertion failure when constant folding BUILD_VECTORS.
svn r139159 caused SelectionDAG::getConstant() to promote BUILD_VECTOR operands
with illegal types, even before type legalization.  For this testcase, that led
to one BUILD_VECTOR with i16 operands and another with promoted i32 operands,
which triggered the assertion.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142370 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-18 17:34:47 +00:00