| Age | Commit message (Collapse) | Author |
|---|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51482 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
I've tried to make the distinction between the DejaGNU tests and the test-suite
more clear, added a small section about generating output from the test-suite,
removed some duplication and fixed some wordings. Most of the changes are text
movements, however.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51480 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51478 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51477 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51476 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51475 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51474 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instruction for doing this?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51473 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51472 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51471 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and/or to handle more cases (such as this add-sitofp.ll testcase), and
port it to selectiondag's ComputeNumSignBits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51469 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and bitcode support for the extractvalue and insertvalue
instructions and constant expressions.
Note that this does not yet include CodeGen support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51468 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
exclude struct and array types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51467 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51465 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
in gcc.dg/pr27531-1.c.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51464 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
many 'ps' load folding patterns in X86InstrSSE.td which are missing the proper alignment checks.
Also fixed some 80 col. violations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51462 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51461 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
exclude struct and array types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51460 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
exclude struct and array types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51459 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
g++.dg/abi/key2.C
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51458 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Reading .bc files from before that change will no longer work.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51457 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
exclude struct and array types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51456 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
will break codegen if relocation model is changed to PIC_ later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51455 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
exclude struct and array types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51452 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51449 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and supported in the grammar, in the lexer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51448 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51441 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
live interval to infinity if the instruction being rewritten is an
original remat def instruction. We were only checking against the clone
of the remat def which doesn't actually appear in the IR at all.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51440 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
generated by the spiller.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51439 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51436 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51435 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
std-conformant even if compiled with exceptions on.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51429 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-O3 x86) substantially (>500 bytes). Reason still unknown.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51423 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
incoming arg.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51422 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
get inline asm working as well as it did previously with the CBE
with the new MRV support for inline asm.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51420 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
with normal outputs. Testcase here:
test/CodeGen/X86/asm-indirect-mem.ll
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51409 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51408 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51407 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
more aggressive, and more correct. Verify that we only attempt to
promote loads and stores.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51406 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51405 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51399 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
that currently uses Type::isFirstClassType and depends on it
returning false for struct or array types.
This commit doesn't change the behavior of Type::isFirstClassType.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51396 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
BB1:
vr1025 = copy vr1024
..
BB2:
vr1024 = op
= op vr1025
<loop eventually branch back to BB1>
Even though vr1025 is copied from vr1024, it's not safe to coalesced them since live range of vr1025 intersects the def of vr1024. This happens when vr1025 is assigned the value of the previous iteration of vr1024 in the loop.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51394 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
they aren't in the header file, systems with a <string> header file that isn't
64-bit clean shouldn't warn if #including Path.h and specifying
-Wshorten-64-to-32.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51393 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51390 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51387 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51386 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
1. The "JITState" object creates a PassManager with the ModuleProvider that the
jit is created with. If the ModuleProvider is removed and deleted, the
PassManager is invalid.
2. The Global maps in the JIT were not invalidated with a ModuleProvider was
removed. This could lead to a case where the Module would be freed, and a
new Module with Globals at the same addresses could return invalid results.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51384 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51375 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51372 91177308-0d34-0410-b5e6-96231b3b80d8
|
