except that the result may not be a constant. Switch jump threading to
use it so that it gets things like (X & 0) -> 0, which occur when phi preds
are deleted and the remaining phi pred was a zero.
llvm-svn: 86637
This patch forbids implicit conversion of DenseMap::const_iterator to
DenseMap::iterator which was possible because DenseMapIterator inherited
(publicly) from DenseMapConstIterator. Conversion the other way around is now
allowed as one may expect.
The template DenseMapConstIterator is removed and the template parameter
IsConst which specifies whether the iterator is constant is added to
DenseMapIterator.
Actually IsConst parameter is not necessary since the constness can be
determined from KeyT but this is not relevant to the fix and can be addressed
later.
Patch by Victor Zverovich!
llvm-svn: 86636
takes decimated instructions and applies identities to them. This
is pretty minimal at this point, but I plan to pull some instcombine
logic out into these and similar routines.
llvm-svn: 86613
was generated. This caused code like this:
## The asm code for the function
.section __TEXT,__const
.align 2
lJTI11_0:
LJTI11_0:
.long LBB11_16
.long LBB11_4
.long LBB11_5
.long LBB11_6
.long LBB11_7
.long LBB11_8
.long LBB11_9
.long LBB11_10
.long LBB11_11
.long LBB11_12
.long LBB11_13
.long LBB11_14
Leh_func_end11: ## <---now in the wrong section!
The `Leh_func_end11' would then end up in the wrong section, causing the
resulting EH frame information to be wrong:
__ZL11CheckRightsjPKcbRbRP6NSData.eh:
.set Lset500eh,Leh_frame_end11-Leh_frame_begin11
.long Lset500eh ; Length of Frame Information Entry
Leh_frame_begin11:
.long Leh_frame_begin11-Leh_frame_common
.long Leh_func_begin11-.
.set Lset501eh,Leh_func_end11-Leh_func_begin11
.long Lset501eh ; FDE address range
`Lset501eh' is now something huge instead of the real value.
The X86 back-end generates the jump table after the EH information is
emitted. Do the same here.
llvm-svn: 86588
the loop. This is needed because with indirectbr it may not be possible
for LoopSimplify to guarantee that all loop exit predecessors are
inside the loop. This fixes PR5437.
LCCSA no longer actually requires LoopSimplify form, but for now it
must still have the dependency because the PassManager doesn't know
how to schedule LoopSimplify otherwise.
llvm-svn: 86569
here:
1) We need to avoid processing sigma nodes as phi nodes for constraint generation.
2) We need to generate constraints for comparisons against constants properly.
This includes our first working ABCD test!
llvm-svn: 86498
graphs being produced. The cause was that we were incorrectly marking sigma instructions as
processed after handling the sigma-specific constraints for them, potentially neglecting to
process them as normal instructions as well.
Unfortunately, the testcase that inspired this still doesn't work because of a bug in the solver,
which is next on the list to debug.
llvm-svn: 86486
when both the source and dest are illegal types, since it would cause
the phi to grow (for example, we shouldn't transform test14b's phi to
a phi on i320). This fixes an infinite loop on i686 bootstrap with
phi slicing turned on, so turn it back on.
llvm-svn: 86483
