| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 171303
|
|
|
|
| |
llvm-svn: 171298
|
|
|
|
|
|
|
|
|
| |
GEP::accumulateConstantOffset().
The later API is nicer than the former, and is correct regarding wrap-around offsets (if anyone cares).
There are a few more places left with duplicated code, which I'll remove soon.
llvm-svn: 171259
|
|
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170502
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
getIntPtrType support for multiple address spaces via a pointer type,
and also introduced a crasher bug in the constant folder reported in
PR14233.
These commits also contained several problems that should really be
addressed before they are re-committed. I have avoided reverting various
cleanups to the DataLayout APIs that are reasonable to have moving
forward in order to reduce the amount of churn, and minimize the number
of commits that were reverted. I've also manually updated merge
conflicts and manually arranged for the getIntPtrType function to stay
in DataLayout and to be defined in a plausible way after this revert.
Thanks to Duncan for working through this exact strategy with me, and
Nick Lewycky for tracking down the really annoying crasher this
triggered. (Test case to follow in its own commit.)
After discussing with Duncan extensively, and based on a note from
Micah, I'm going to continue to back out some more of the more
problematic patches in this series in order to ensure we go into the
LLVM 3.2 branch with a reasonable story here. I'll send a note to
llvmdev explaining what's going on and why.
Summary of reverted revisions:
r166634: Fix a compiler warning with an unused variable.
r166607: Add some cleanup to the DataLayout changes requested by
Chandler.
r166596: Revert "Back out r166591, not sure why this made it through
since I cancelled the command. Bleh, sorry about this!
r166591: Delete a directory that wasn't supposed to be checked in yet.
r166578: Add in support for getIntPtrType to get the pointer type based
on the address space.
llvm-svn: 167221
|
|
|
|
|
|
|
|
|
| |
address space.
This checkin also adds in some tests that utilize these paths and updates some of the
clients.
llvm-svn: 166578
|
|
|
|
| |
llvm-svn: 165551
|
|
|
|
|
|
|
|
| |
methods for them.
No functionality change intended.
llvm-svn: 165466
|
|
|
|
| |
llvm-svn: 165402
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This disables malloc-specific optimization when -fno-builtin (or -ffreestanding)
is specified. This has been a problem for a long time but became more severe
with the recent memory builtin improvements.
Since the memory builtin functions are used everywhere, this required passing
TLI in many places. This means that functions that now have an optional TLI
argument, like RecursivelyDeleteTriviallyDeadFunctions, won't remove dead
mallocs anymore if the TLI argument is missing. I've updated most passes to do
the right thing.
Fixes PR13694 and probably others.
llvm-svn: 162841
|
|
|
|
|
|
|
|
|
|
| |
The previous fix only checked for simple cycles, use a set to catch longer
cycles too.
Drop the broken check from the ObjectSizeOffsetEvaluator. The BoundsChecking
pass doesn't have to deal with invalid IR like InstCombine does.
llvm-svn: 162120
|
|
|
|
|
|
|
|
| |
unreachable code due to constant propagation.
Fixes PR13621.
llvm-svn: 162098
|
|
|
|
| |
llvm-svn: 160876
|
|
|
|
|
|
|
| |
original commit msg:
MemoryBuiltins: add support to determine the size of strdup'ed non-constant strings
llvm-svn: 160751
|
|
|
|
|
|
| |
strings
llvm-svn: 160742
|
|
|
|
| |
llvm-svn: 160676
|
|
|
|
|
|
|
|
| |
discussed 2 months ago or so.
Make sure we do not emit index computations with NSW flags so that we dont get an undef value if the GEP overflows
llvm-svn: 160589
|
|
|
|
|
|
| |
Unfortunately this change requires the cache map to hold WeakVHs instead
llvm-svn: 159667
|
|
|
|
|
|
|
|
| |
- recognize C++ new(std::nothrow) friends
- ignore ExtractElement and ExtractValue instructions in size/offset analysis (all easy cases are probably folded away before we get here)
- also recognize realloc as noalias
llvm-svn: 159356
|
|
|
|
| |
llvm-svn: 159145
|
|
|
|
| |
llvm-svn: 158999
|
|
|
|
|
|
| |
user. Update GlobalOpt accordingly.
llvm-svn: 158952
|
|
|
|
|
|
|
|
| |
Update comments accordingly.
Make instcombine remove useless invokes to C++'s 'new' allocation function (test attached).
llvm-svn: 158937
|
|
|
|
|
|
| |
Thanks to Chandler for pointing out the problem.
llvm-svn: 158928
|
|
|
|
|
|
| |
and were crashing this code on 64 bits machines
llvm-svn: 158923
|
|
|
|
|
|
|
|
|
|
|
|
| |
- provide more extensive set of functions to detect library allocation functions (e.g., malloc, calloc, strdup, etc)
- provide an API to compute the size and offset of an object pointed by
Move a few clients (GVN, AA, instcombine, ...) to the new API.
This implementation is a lot more aggressive than each of the custom implementations being replaced.
Patch reviewed by Nick Lewycky and Chandler Carruth, thanks.
llvm-svn: 158919
|
|
|
|
|
|
|
|
| |
being done for malloc)
fix a few typos found by Chad in my previous commit
llvm-svn: 156110
|
|
|
|
| |
llvm-svn: 156102
|
|
|
|
|
|
| |
Fixes PR11426. Not sure if a test case with a "wrong" malloc would be useful.
llvm-svn: 145106
|
|
|
|
| |
llvm-svn: 135375
|
|
|
|
| |
llvm-svn: 133362
|
|
|
|
| |
llvm-svn: 127801
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
memory builtins as equivalent to malloc/free.
This is different from any attribute we have. For example, you can delete the
allocators when their result is unused, but you can't collapse two calls to the
same function, even if no global/memory state has changed in between. The
noalias return states that the result does not alias any other pointer, but
instcombine optimizes malloc() as though the result is non-null for the purpose
of eliminating unused pointers.
llvm-svn: 127673
|
|
|
|
| |
llvm-svn: 106686
|
|
|
|
| |
llvm-svn: 106685
|
|
|
|
|
|
|
| |
Probably the best way to know that all getOperand() calls have been handled
is to replace that API instead of updating.
llvm-svn: 101579
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with a fix for self-hosting
rotate CallInst operands, i.e. move callee to the back
of the operand array
the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary
llvm-svn: 101465
|
|
|
|
| |
llvm-svn: 101434
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with a fix
rotate CallInst operands, i.e. move callee to the back
of the operand array
the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary
llvm-svn: 101397
|
|
|
|
| |
llvm-svn: 101368
|
|
|
|
|
|
|
|
|
|
| |
of the operand array
the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary
llvm-svn: 101364
|
|
|
|
| |
llvm-svn: 99564
|
|
|
|
| |
llvm-svn: 95781
|
|
|
|
| |
llvm-svn: 89175
|
|
|
|
|
|
| |
size associated with a malloc; also extend PerformHeapAllocSRoA() to check if the optimized malloc's arg had its highest bit set, so that it is safe for ComputeMultiple() to look through sext instructions while determining the optimized malloc's array size
llvm-svn: 86676
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
from various APIs, addressing PR5325.
llvm-svn: 86231
|
|
|
|
| |
llvm-svn: 86213
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|