| Age | Commit message (Collapse) | Author |
|---|
|
------------------------------------------------------------------------
r155984 | void | 2012-05-02 02:59:45 -0700 (Wed, 02 May 2012) | 4 lines
The value held in the vector may be RAUW'ed by some of the canonicalization
methods. Use a weak value handle to keep up with this.
PR12245
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155985 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r155954 | void | 2012-05-01 15:50:45 -0700 (Tue, 01 May 2012) | 3 lines
Strip the pointer casts off of allocas so that the selection DAG can find them.
PR10799
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155955 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r155817 | void | 2012-04-30 03:44:54 -0700 (Mon, 30 Apr 2012) | 9 lines
Second attempt at PR12573:
Allow the "SplitCriticalEdge" function to split the edge to a landing pad. If
the pass is *sure* that it thinks it knows what it's doing, then it may go ahead
and specify that the landing pad can have its critical edge split. The loop
unswitch pass is one of these passes. It will split the critical edges of all
edges coming from a loop to a landing pad not within the loop. Doing so will
retain important loop analysis information, such as loop simplify.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155833 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r155809 | rafael | 2012-04-29 20:53:06 -0700 (Sun, 29 Apr 2012) | 2 lines
Make sure HoistInsertPosition finds a position that is dominated by all
inputs.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155828 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r155818 | baldrick | 2012-04-30 04:56:58 -0700 (Mon, 30 Apr 2012) | 3 lines
Just mark the sign bit as known zero, rather than any other irrelevant bits
known zero in the LHS. Fixes PR12541.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155827 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r155668 | atrick | 2012-04-26 14:48:25 -0700 (Thu, 26 Apr 2012) | 8 lines
Fix the SD scheduler to avoid gluing the same node twice.
DAGCombine strangeness may result in multiple loads from the same
offset. They both may try to glue themselves to another load. We could
insist that the redundant loads glue themselves to each other, but the
beter fix is to bail out from bad gluing at the time we detect it.
Fixes rdar://11314175: BuildSchedUnits assert.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155672 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r155466 | chandlerc | 2012-04-24 11:42:47 -0700 (Tue, 24 Apr 2012) | 17 lines
Fix a crash on valid (if UB) bitcode that is produced for some global
constants in C++11 mode. I have no idea why it required such particular
circumstances to get here, the code seems clearly to rely upon unchecked
assumptions.
Specifically, when we decide to form an index into a struct type, we may
have gone through (at least one) zero-length array indexing round, which
would have left the offset un-adjusted, and thus not necessarily valid
for use when indexing the struct type.
This is just an canonicalization step, so the correct thing is to refuse
to canonicalize nonsensical GEPs of this form. Implemented, and test
case added.
Fixes PR12642. Pair debugged and coded with Richard Smith. =] I credit
him with most of the debugging, and preventing me from writing the wrong
code.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155506 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155010 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155009 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155004 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instructions on ARM. Now the diasassembler emmits warnings instead of errors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155002 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
disassembler. Since the upredicability conditions are complex, C++ code was added to handle them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155001 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
coprocessor number was removed for this instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155000 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instructions in the disassembler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154999 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Fixes build on MSVC
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154970 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154967 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
also fix SimplifyLibCalls to use TLI rather than compile-time conditionals to enable optimizations on floor, ceil, round, rint, and nearbyint
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154960 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Vladimir Medic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154935 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This made the test fail with -mcpu=generic (when building on a non-x86 host).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154926 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154915 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
has NUW but not NSW."
This isn't right either, reverting for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154910 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154908 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instructions with writebacks. And add test a case for all opcodes handed by
DecodeVLD2DupInstruction() in ARMDisassembler.cpp .
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154884 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
live-ins is properly enabled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154882 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154877 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rdar://11252521
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154875 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154870 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
both fallthrough and a conditional branch target the same successor.
Gracefully delete the conditional branch and introduce any unconditional
branch needed to reach the actual successor. This fixes memory
corruption in 2009-06-15-RegScavengerAssert.ll and possibly other tests.
Also, while I'm here fix a latent bug I spotted by inspection. I never
applied the same fundamental fix to this fallthrough successor finding
logic that I did to the logic used when there are no conditional
branches. As a consequence it would have selected landing pads had they
be aligned in just the right way here. I don't have a test case as
I spotted this by inspection, and the previous time I found this
required have of TableGen's source code to produce it. =/ I hate backend
bugs. ;]
Thanks to Jim Grosbach for helping me reason through this and reviewing
the fix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154867 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
A trailing comma means no argument at all (i.e., as if the comma were not
present), not an empty argument to the invokee.
rdar://11252521
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154863 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Add an extra test to ldr_post with an immediate increment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154859 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It makes it less sensitive to small changes in heuristics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154857 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154850 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
catch it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154845 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
1. CHECKNEXT was used instead of CHECK-NEXT which caused the line to be
ignored which in turn hid the next 2 problems:
2. ('sh_offset', 0x{{{[0-9,a-f]+}}) had one too many leading curly braces and
failed to do it's job of accepting all hex digits and:
3. The check for the hex values for the code instructions didn't account for
blank separators.
Patch by Jack Carter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154842 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rdar://11252521
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154840 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154839 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154838 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rdar://11252521
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154832 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154831 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154825 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
through the use of 'fpmath' metadata. Currently this only provides a 'fpaccuracy'
value, which may be a number in ULPs or the keyword 'fast', however the intent is
that this will be extended with additional information about NaN's, infinities
etc later. No optimizations have been hooked up to this so far.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154822 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is mostly to test the waters. I'd like to get results from FNT
build bots and other bots running on non-x86 platforms.
This feature has been pretty heavily tested over the last few months by
me, and it fixes several of the execution time regressions caused by the
inlining work by preventing inlining decisions from radically impacting
block layout.
I've seen very large improvements in yacr2 and ackermann benchmarks,
along with the expected noise across all of the benchmark suite whenever
code layout changes. I've analyzed all of the regressions and fixed
them, or found them to be impossible to fix. See my email to llvmdev for
more details.
I'd like for this to be in 3.1 as it complements the inliner changes,
but if any failures are showing up or anyone has concerns, it is just
a flag flip and so can be easily turned off.
I'm switching it on tonight to try and get at least one run through
various folks' performance suites in case SPEC or something else has
serious issues with it. I'll watch bots and revert if anything shows up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154816 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
once we start changing the block layout, so just nuke it. If anyone has
ideas about how to craft a code layout agnostic form of the test please
let me know.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154815 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rotation. When there is a loop backedge which is an unconditional
branch, we will end up with a branch somewhere no matter what. Try
placing this backedge in a fallthrough position above the loop header as
that will definitely remove at least one branch from the loop iteration,
where whole loop rotation may not.
I haven't seen any benchmarks where this is important but loop-blocks.ll
tests for it, and so this will be covered when I flip the default.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154812 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also refactor so all MC paraphernalia are created once for all uses as much as possible.
The test change is to account for the fact that the default disassembler behaviour has changed with regards to specifying the assembly syntax to use.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154809 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
laid out in a form with a fallthrough into the header and a fallthrough
out of the bottom. In that case, leave the loop alone because any
rotation will introduce unnecessary branches. If either side looks like
it will require an explicit branch, then the rotation won't add any, do
it to ensure the branch occurs outside of the loop (if possible) and
maximize the benefit of the fallthrough in the bottom.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154806 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154786 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a complex change that resulted from a great deal of
experimentation with several different benchmarks. The one which proved
the most useful is included as a test case, but I don't know that it
captures all of the relevant changes, as I didn't have specific
regression tests for each, they were more the result of reasoning about
what the old algorithm would possibly do wrong. I'm also failing at the
moment to craft more targeted regression tests for these changes, if
anyone has ideas, it would be welcome.
The first big thing broken with the old algorithm is the idea that we
can take a basic block which has a loop-exiting successor and a looping
successor and use the looping successor as the layout top in order to
get that particular block to be the bottom of the loop after layout.
This happens to work in many cases, but not in all.
The second big thing broken was that we didn't try to select the exit
which fell into the nearest enclosing loop (to which we exit at all). As
a consequence, even if the rotation worked perfectly, it would result in
one of two bad layouts. Either the bottom of the loop would get
fallthrough, skipping across a nearer enclosing loop and thereby making
it discontiguous, or it would be forced to take an explicit jump over
the nearest enclosing loop to earch its successor. The point of the
rotation is to get fallthrough, so we need it to fallthrough to the
nearest loop it can.
The fix to the first issue is to actually layout the loop from the loop
header, and then rotate the loop such that the correct exiting edge can
be a fallthrough edge. This is actually much easier than I anticipated
because we can handle all the hard parts of finding a viable rotation
before we do the layout. We just store that, and then rotate after
layout is finished. No inner loops get split across the post-rotation
backedge because we check for them when selecting the rotation.
That fix exposed a latent problem with our exitting block selection --
we should allow the backedge to point into the middle of some inner-loop
chain as there is no real penalty to it, the whole point is that it
*won't* be a fallthrough edge. This may have blocked the rotation at all
in some cases, I have no idea and no test case as I've never seen it in
practice, it was just noticed by inspection.
Finally, all of these fixes, and studying the loops they produce,
highlighted another problem: in rotating loops like this, we sometimes
fail to align the destination of these backwards jumping edges. Fix this
by actually walking the backwards edges rather than relying on loopinfo.
This fixes regressions on heapsort if block placement is enabled as well
as lots of other cases where the previous logic would introduce an
abundance of unnecessary branches into the execution.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154783 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
normal shuffle vectors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154778 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Use non-vex instructions for SSE4.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154770 91177308-0d34-0410-b5e6-96231b3b80d8
|
