| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
predecessor, instead of removing it. This fixes following tests from llvmgcc42 testsuite.
gcc.c-torture/execute/20000605-3.c
gcc.c-torture/execute/20020619-1.c
gcc.c-torture/execute/20030920-1.c
gcc.c-torture/execute/loop-ivopts-1.c
llvm-svn: 65353
|
|
|
|
|
|
| |
llvm.dbg.func.start also.
llvm-svn: 64278
|
|
|
|
| |
llvm-svn: 64242
|
|
|
|
| |
llvm-svn: 63802
|
|
|
|
| |
llvm-svn: 63781
|
|
|
|
| |
llvm-svn: 63700
|
|
|
|
|
|
| |
the branch block.
llvm-svn: 63687
|
|
|
|
| |
llvm-svn: 63671
|
|
|
|
| |
llvm-svn: 62758
|
|
|
|
|
|
| |
start failing.
llvm-svn: 62578
|
|
|
|
| |
llvm-svn: 62561
|
|
|
|
|
|
| |
trapping instruction be executed unconditionally.
llvm-svn: 62541
|
|
|
|
| |
llvm-svn: 62536
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llvm-gcc. Most likely, it's miscompiling one of the "gen*" programs:
/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm-gcc.obj/./prev-gcc/xgcc -B/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm-gcc.obj/./prev-gcc/ -B/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm-gcc.install/i386-apple-darwin9.6.0/bin/ -c -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -mdynamic-no-pic -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../llvm-gcc.src/gcc -I../../llvm-gcc.src/gcc/build -I../../llvm-gcc.src/gcc/../include -I./../intl -I../../llvm-gcc.src/gcc/../libcpp/include -I../../llvm-gcc.src/gcc/../libdecnumber -I../libdecnumber -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.obj/include -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.src/include -DENABLE_LLVM -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.obj/../llvm.src/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -o build/gencondmd.o build/gencondmd.c
../../llvm-gcc.src/gcc/config/i386/mmx.md:926: error: expected '}' before ')' token
../../llvm-gcc.src/gcc/config/i386/mmx.md:926: warning: excess elements in struct initializer
../../llvm-gcc.src/gcc/config/i386/mmx.md:926: warning: (near initialization for 'insn_conditions[4]')
../../llvm-gcc.src/gcc/config/i386/mmx.md:926: error: expected '}' before ')' token
../../llvm-gcc.src/gcc/config/i386/mmx.md:926: error: expected ',' or ';' before ')' token
../../llvm-gcc.src/gcc/config/i386/mmx.md:927: error: expected identifier or '(' before ',' token
../../llvm-gcc.src/gcc/config/i386/sse.md:3458: error: expected identifier or '(' before ',' token
...
llvm-svn: 62506
|
|
|
|
|
|
|
|
|
| |
we assumed a CFG structure that would be valid when all code in
the function is reachable, but not all code is necessarily
reachable. Do a simple, but horrible, CFG walk to check for this
case.
llvm-svn: 62487
|
|
|
|
|
|
|
|
| |
consistently for deleting branches. In addition to being slightly
more readable, this makes SimplifyCFG a bit better
about cleaning up after itself when it makes conditions unused.
llvm-svn: 61100
|
|
|
|
|
|
|
| |
nodes. FoldSingleEntryPHINodes deletes the PHI, so there is no
need to delete it afterward.
llvm-svn: 60653
|
|
|
|
|
|
|
| |
I don't really see this as being needed, but there is little harm from doing
it.
llvm-svn: 58385
|
|
|
|
|
|
| |
While hosting instruction check PHI node.
llvm-svn: 57025
|
|
|
|
|
|
| |
branch condition.
llvm-svn: 56286
|
|
|
|
| |
llvm-svn: 55971
|
|
|
|
| |
llvm-svn: 54832
|
|
|
|
|
|
| |
fixes PR2540.
llvm-svn: 53533
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
triangle shape and it contains a single, side effect free, cheap instruction. The branch is eliminated by adding a select instruction. i.e.
Turn
BB:
%t1 = icmp
br i1 %t1, label %BB1, label %BB2
BB1:
%t3 = add %t2, c
br label BB2
BB2:
=>
BB:
%t1 = icmp
%t4 = add %t2, c
%t3 = select i1 %t1, %t2, %t3
llvm-svn: 52073
|
|
|
|
| |
llvm-svn: 52072
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SimplifyCFG pass looks at basic blocks that contain only phi nodes,
followed by an unconditional branch. In a lot of cases, such a block (BB) can
be merged into their successor (Succ).
This merging is performed by TryToSimplifyUncondBranchFromEmptyBlock. It does
this by taking all phi nodes in the succesor block Succ and expanding them to
include the predecessors of BB. Furthermore, any phi nodes in BB are moved to
Succ and expanded to include the predecessors of Succ as well.
Before attempting this merge, CanPropagatePredecessorsForPHIs checks to see if
all phi nodes can be properly merged. All functional changes are made to
this function, only comments were updated in
TryToSimplifyUncondBranchFromEmptyBlock.
In the original code, CanPropagatePredecessorsForPHIs looks quite convoluted
and more like stack of checks added to handle different kinds of situations
than a comprehensive check. In particular the first check in the function did
some value checking for the case that BB and Succ have a common predecessor,
while the last check in the function simply rejected all cases where BB and
Succ have a common predecessor. The first check was still useful in the case
that BB did not contain any phi nodes at all, though, so it was not completely
useless.
Now, CanPropagatePredecessorsForPHIs is restructured to to look a lot more
similar to the code that actually performs the merge. Both functions now look
at the same phi nodes in about the same order. Any conflicts (phi nodes with
different values for the same source) that could arise from merging or moving
phi nodes are detected. If no conflicts are found, the merge can happen.
Apart from only restructuring the checks, two main changes in functionality
happened.
Firstly, the old code rejected blocks with common predecessors in most cases.
The new code performs some extra checks so common predecessors can be handled
in a lot of cases. Wherever common predecessors still pose problems, the
blocks are left untouched.
Secondly, the old code rejected the merge when values (phi nodes) from BB were
used in any other place than Succ. However, it does not seem that there is any
situation that would require this check. Even more, this can be proven.
Consider that BB is a block containing of a single phi node "%a" and a branch
to Succ. Now, since the definition of %a will dominate all of its uses, BB
will dominate all blocks that use %a. Furthermore, since the branch from BB to
Succ is unconditional, Succ will also dominate all uses of %a.
Now, assume that one predecessor of Succ is not dominated by BB (and thus not
dominated by Succ). Since at least one use of %a (but in reality all of them)
is reachable from Succ, you could end up at a use of %a without passing
through it's definition in BB (by coming from X through Succ). This is a
contradiction, meaning that our original assumption is wrong. Thus, all
predecessors of Succ must also be dominated by BB (and thus also by Succ).
This means that moving the phi node %a from BB to Succ does not pose any
problems when the two blocks are merged, and any use checks are not needed.
llvm-svn: 51478
|
|
|
|
| |
llvm-svn: 51349
|
|
|
|
|
|
| |
renaming to isnan2. Now that no test has llx ending there is no need to search for them from dg.exp too.
llvm-svn: 51328
|
|
|
|
| |
llvm-svn: 50560
|
|
|
|
|
|
|
|
| |
multiple return values.
Bill, please pull this into Tak.
llvm-svn: 50332
|
|
|
|
|
|
| |
r48047 r48084 r48085 r48086 r48088 r48096 r48099 r48109 and r48123.
llvm-svn: 50265
|
|
|
|
|
|
|
| |
Fix said code to handle merging return instructions together correctly
when handling multiple return values.
llvm-svn: 50199
|
|
|
|
| |
llvm-svn: 48536
|
|
|
|
| |
llvm-svn: 48483
|
|
|
|
|
|
|
|
| |
before trying to merge the block into its predecessors.
This allows two-entry-phi-return.ll to be simplified
into a single basic block.
llvm-svn: 48252
|
|
|
|
|
|
| |
optimized away before it tests what it is intended to test.
llvm-svn: 48251
|
|
|
|
| |
llvm-svn: 48207
|
|
|
|
| |
llvm-svn: 48137
|
|
|
|
| |
llvm-svn: 48123
|
|
|
|
|
|
|
| |
Secondly, we have to check whether the branch is actually pointing to the block
with the unwind in it. We could have gotten here because of the unwind_to alone.
llvm-svn: 48099
|
|
|
|
|
|
| |
at all.
llvm-svn: 48096
|
|
|
|
| |
llvm-svn: 48086
|
|
|
|
|
|
|
| |
could theoretically introduce a trap, but is also a performance issue.
This speeds up ptrdist/ks by 8%.
llvm-svn: 45533
|
|
|
|
| |
llvm-svn: 45389
|
|
|
|
|
|
|
| |
not merge current bb and succ even if bb's terminator is
unconditional branch to succ.
llvm-svn: 45305
|
|
|
|
|
|
| |
use them.
llvm-svn: 44403
|
|
|
|
|
|
|
|
|
|
|
|
| |
the function type, instead they belong to functions
and function calls. This is an updated and slightly
corrected version of Reid Spencer's original patch.
The only known problem is that auto-upgrading of
bitcode files doesn't seem to work properly (see
test/Bitcode/AutoUpgradeIntrinsics.ll). Hopefully
a bitcode guru (who might that be? :) ) will fix it.
llvm-svn: 44359
|
|
|
|
| |
llvm-svn: 44280
|
|
|
|
|
|
| |
by inserting unreachable after no-return calls.
llvm-svn: 44099
|
|
|
|
|
|
| |
and simplifycfg in the rare cases when it is needed.
llvm-svn: 44044
|