| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
makes several optimization passes abort in cases where they're currently
silently miscompiling code.
Remove the indirectbr assertion from SplitEdge. Indirectbr is only
a problem for critical edges, and SplitEdge defers to SplitCriticalEdge
to handle those, and SplitCriticalEdge has its own assertion for
indirectbr.
llvm-svn: 86147
|
| |
|
|
| |
llvm-svn: 86141
|
| |
|
|
| |
llvm-svn: 86133
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 86077
|
| |
|
|
|
|
| |
Hans Wennborg!
llvm-svn: 86067
|
| |
|
|
|
|
| |
resizes in IPSCCP. This fixes PR5394.
llvm-svn: 86036
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
to EmitGEPOffset.
Implement some new transforms for optimizing
subtracts of two pointer to ints into the same vector. This happens
for C++ iterator idioms for example, stringmap takes a const char*
that points to the start and end of a string. Once inlined, we want
the pointer difference to turn back into a length.
This is rdar://7362831.
llvm-svn: 86021
|
| |
|
|
|
|
|
| |
more aggressive an correct. This survives building llvm in 64-bit
mode with optimizations and the built llvm passes make check.
llvm-svn: 85973
|
| |
|
|
| |
llvm-svn: 85937
|
| |
|
|
|
|
|
|
|
|
| |
functions that don't have local linkage. Basically, we need to be more
careful about propagating argument information to functions whose results
we aren't tracking. This fixes a miscompilation of
LLVMCConfigurationEmitter.cpp when built with an llvm-gcc that has ipsccp
enabled.
llvm-svn: 85923
|
| |
|
|
|
|
| |
to follow.
llvm-svn: 85903
|
| |
|
|
| |
llvm-svn: 85896
|
| |
|
|
| |
llvm-svn: 85863
|
| |
|
|
| |
llvm-svn: 85859
|
| |
|
|
| |
llvm-svn: 85858
|
| |
|
|
|
|
| |
std::map to DenseMap, exposed on release llvm-gcc bootstrap.
llvm-svn: 85840
|
| |
|
|
| |
llvm-svn: 85818
|
| |
|
|
|
|
| |
disable it until I can fix it.
llvm-svn: 85810
|
| |
|
|
|
|
|
|
|
| |
function to calls of that function, regardless of whether it has local
linkage or has its address taken. Not escaping should only affect
whether we make an aggressive assumption about the arguments to a
function, not whether we can track the result of it.
llvm-svn: 85795
|
| |
|
|
| |
llvm-svn: 85793
|
| |
|
|
|
|
| |
a shared place instead of duplicating it 4 times.
llvm-svn: 85792
|
| |
|
|
|
|
| |
"multiple return values" but not "first class aggregates"
llvm-svn: 85791
|
| |
|
|
| |
llvm-svn: 85790
|
| |
|
|
|
|
|
| |
instead of reinventing SCCP-specific logic. This gives us
new powers.
llvm-svn: 85789
|
| |
|
|
|
|
|
|
|
|
|
| |
a DenseMap. Doing this required being aware of subtle iterator
invalidation issues, but it provides a big speedup. In a
release-asserts build, this sped up optimizing 403.gcc from
1.34s -> 0.79s (IPSCCP) and 1.11s -> 0.44s (SCCP).
This commit also conflates in a bunch of general cleanups, sorry.
llvm-svn: 85788
|
| |
|
|
| |
llvm-svn: 85786
|
| |
|
|
|
|
| |
an assertion on the buildbot.
llvm-svn: 85784
|