| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 86635
|
| |
|
|
|
|
| |
simplification, this handles the foldable fcmp x,x cases among many others.
llvm-svn: 86627
|
| |
|
|
| |
llvm-svn: 86625
|
| |
|
|
|
|
|
| |
Simplify[IF]Cmp pieces. Add some predicates to CmpInst to
determine whether a predicate is fp or int.
llvm-svn: 86624
|
| |
|
|
|
|
| |
individual operands instead of taking a temporary array
llvm-svn: 86619
|
| |
|
|
| |
llvm-svn: 86616
|
| |
|
|
|
|
|
| |
simplifies instruction users of PHIs when the phi is eliminated. This
will be moved to transforms/utils after some other refactoring.
llvm-svn: 86603
|
| |
|
|
| |
llvm-svn: 86575
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
it to a normal binop. Patch by Alastair Lynn, testcase by me.
llvm-svn: 86524
|
| |
|
|
|
|
| |
putchar in case there is an error.
llvm-svn: 86515
|
| |
|
|
|
|
| |
used by a chain of other PHIs.
llvm-svn: 86503
|
| |
|
|
| |
llvm-svn: 86499
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
two problems addressed
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
|
| |
|
|
| |
llvm-svn: 86497
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
different constraint
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
|
| |
|
|
|
|
| |
(SliceUpIllegalIntegerPHI) disabled.
llvm-svn: 86480
|
| |
|
|
|
|
| |
llvm-gcc bootstrap.
llvm-svn: 86478
|
| |
|
|
|
|
|
|
| |
not turn a PHI in a legal type into a PHI of an illegal type, and
add a new optimization that breaks up insane integer PHI nodes into
small pieces (PR3451).
llvm-svn: 86443
|
| |
|
|
| |
llvm-svn: 86403
|
| |
|
|
|
|
|
|
|
|
| |
(eliminating some extends) if the new type of the
computation is legal or if both the source and dest
are illegal. This prevents instcombine from changing big
chains of computation into i64 on 32-bit targets for
example.
llvm-svn: 86398
|
| |
|
|
|
|
| |
llvm-gcc-i386-darwin9 build bot.
llvm-svn: 86391
|
| |
|
|
|
|
| |
a store.
llvm-svn: 86359
|
| |
|
|
|
|
|
|
|
| |
(making pred factoring only happen if threading is guaranteed
to be successful).
This now survives an X86-64 bootstrap of llvm-gcc.
llvm-svn: 86355
|
| |
|
|
|
|
| |
things. Back out part of r86349 for a moment.
llvm-svn: 86353
|
| |
|
|
|
|
| |
and add a .ll to demo the new capability.
llvm-svn: 86349
|
| |
|
|
|
|
|
| |
86289, 86278, 86270, 86267, 86266 & 86264
Chris, please take a look.
llvm-svn: 86321
|
| |
|
|
|
|
|
|
| |
bitcast
- fix ProcessInternalGlobal() debug output
llvm-svn: 86317
|
| |
|
|
| |
llvm-svn: 86314
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here is the original commit message:
This commit updates malloc optimizations to operate on malloc calls that have constant int size arguments.
Update CreateMalloc so that its callers specify the size to allocate:
MallocInst-autoupgrade users use non-TargetData-computed allocation sizes.
Optimization uses use TargetData to compute the allocation size.
Now that malloc calls can have constant sizes, update isArrayMallocHelper() to use TargetData to determine the size of the malloced type and the size of malloced arrays.
Extend getMallocType() to support malloc calls that have non-bitcast uses.
Update OptimizeGlobalAddressOfMalloc() to optimize malloc calls that have non-bitcast uses. The bitcast use of a malloc call has to be treated specially here because the uses of the bitcast need to be replaced and the bitcast needs to be erased (just like the malloc call) for OptimizeGlobalAddressOfMalloc() to work correctly.
Update PerformHeapAllocSRoA() to optimize malloc calls that have non-bitcast uses. The bitcast use of the malloc is not handled specially here because ReplaceUsesOfMallocWithGlobal replaces through the bitcast use.
Update OptimizeOnceStoredGlobal() to not care about the malloc calls' bitcast use.
Update all globalopt malloc tests to not rely on autoupgraded-MallocInsts, but instead use explicit malloc calls with correct allocation sizes.
llvm-svn: 86311
|
| |
|
|
|
|
| |
set only once even if it has multiple edges to BB.
llvm-svn: 86299
|
| |
|
|
| |
llvm-svn: 86289
|
| |
|
|
| |
llvm-svn: 86278
|
| |
|
|
| |
llvm-svn: 86270
|
| |
|
|
| |
llvm-svn: 86267
|
| |
|
|
| |
llvm-svn: 86266
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
predicates. This allows us to jump thread things like:
_ZN12StringSwitchI5ColorE4CaseILj7EEERS1_RAT__KcRKS0_.exit119:
%tmp1.i24166 = phi i8 [ 1, %bb5.i117 ], [ %tmp1.i24165, %_Z....exit ], [ %tmp1.i24165, %bb4.i114 ]
%toBoolnot.i87 = icmp eq i8 %tmp1.i24166, 0 ; <i1> [#uses=1]
%tmp4.i90 = icmp eq i32 %tmp2.i, 6 ; <i1> [#uses=1]
%or.cond173 = and i1 %toBoolnot.i87, %tmp4.i90 ; <i1> [#uses=1]
br i1 %or.cond173, label %bb4.i96, label %_ZN12...
Where it is "obvious" that when coming from %bb5.i117 that the 'and' is always
false. This triggers a surprisingly high number of times in the testsuite,
and gets us closer to generating good code for doug's strswitch testcase.
This also make a bunch of other code in jump threading redundant, I'll rip
out in the next patch. This survived an enable-checking llvm-gcc bootstrap.
llvm-svn: 86264
|
| |
|
|
| |
llvm-svn: 86235
|
| |
|
|
|
|
| |
from various APIs, addressing PR5325.
llvm-svn: 86231
|
| |
|
|
| |
llvm-svn: 86213
|
| |
|
|
| |
llvm-svn: 86193
|
| |
|
|
|
|
|
| |
on loops having dedicated exits, which LoopSimplify can no longer always
guarantee.
llvm-svn: 86181
|
| |
|
|
| |
llvm-svn: 86180
|
| |
|
|
|
|
|
|
|
| |
unsplittable critical edges, which means the introduction of
loops which cannot be transformed to LoopSimplify form. Fix
LoopSimplify to avoid transforming such loops into invalid
code.
llvm-svn: 86176
|
| |
|
|
|
|
| |
LoopSimplify form may not be available.
llvm-svn: 86175
|
| |
|
|
| |
llvm-svn: 86164
|
| |
|
|
|
|
| |
LoopPassManager for it.
llvm-svn: 86163
|
| |
|
|
| |
llvm-svn: 86160
|