| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 90738
|
|
|
|
| |
llvm-svn: 90581
|
|
|
|
| |
llvm-svn: 90572
|
|
|
|
| |
llvm-svn: 90553
|
|
|
|
|
|
| |
that contains an instruction
llvm-svn: 90512
|
|
|
|
|
|
| |
Patch by Howard Hinnant!
llvm-svn: 90365
|
|
|
|
|
|
| |
for pointing this out.
llvm-svn: 90015
|
|
|
|
| |
llvm-svn: 89976
|
|
|
|
| |
llvm-svn: 89974
|
|
|
|
|
|
|
| |
out of its run function and into its doInitialization method, so
that it does the dump once instead of once per function.
llvm-svn: 89660
|
|
|
|
|
|
|
|
|
|
|
|
| |
the body to not pass the name for the isSigned parameter. However it
seems that changing prototypes is a big-no-no, so here I revert the
previous change and pass "true" for isSigned, meaning this always does
a signed cast, which was the previous behaviour assuming the name was
not NULL! Some other C function needs to be introduced for the general
case of signed or unsigned casts. This hopefully unbreaks the ocaml
binding.
llvm-svn: 89648
|
|
|
|
| |
llvm-svn: 89646
|
|
|
|
|
|
| |
right type.
llvm-svn: 89014
|
|
|
|
| |
llvm-svn: 88910
|
|
|
|
|
|
| |
differentiate PseudoSourceValueVal from FixedStackPseudoSourceValueVal at this level?
llvm-svn: 88902
|
|
|
|
| |
llvm-svn: 88716
|
|
|
|
|
|
| |
got ghost linkage. It's better than aborting.
llvm-svn: 88715
|
|
|
|
|
|
|
| |
This allows StringRef to skip controversial if(str) check in constructor.
Buildbots, wait for corresponding clang and llvm-gcc FE check-ins!
llvm-svn: 86914
|
|
|
|
| |
llvm-svn: 86846
|
|
|
|
|
|
| |
correctly
llvm-svn: 86712
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
lame API.
Also, Stringrefify some more MemoryBuffer functions, and add two performance FIXMEs.
llvm-svn: 86630
|
|
|
|
| |
llvm-svn: 86525
|
|
|
|
| |
llvm-svn: 86365
|
|
|
|
| |
llvm-svn: 86316
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
with correct calling convention
llvm-svn: 86290
|
|
|
|
| |
llvm-svn: 86251
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
and avoid redundant isFreeCall cases) in feedback to r85176
llvm-svn: 85936
|
|
|
|
|
|
|
| |
can be banging on a context at a time, this isn't needed. Owen, please
review.
llvm-svn: 85728
|
|
|
|
| |
llvm-svn: 85722
|
|
|
|
|
|
| |
block had its address taken even if the blockaddress was dead.
llvm-svn: 85706
|
|
|
|
|
|
| |
maintain the block use count in SubclassData.
llvm-svn: 85701
|
|
|
|
|
|
|
| |
indirectbr, thus we don't need "blockaddr(@func, null)". Eliminate it
for simplicity.
llvm-svn: 85699
|
|
|
|
|
|
|
|
|
|
|
|
| |
block with a blockaddress still referring to it' replace the invalid
blockaddress with a new blockaddress(@func, null) instead of a
inttoptr(1).
This changes the bitcode encoding format, and still needs codegen
support (this should produce a non-zero value, referring to the entry
block of the function would also be quite reasonable).
llvm-svn: 85678
|
|
|
|
|
|
|
| |
around, then zap them. This is analogous to dangling constantexprs hanging
off functions.
llvm-svn: 85627
|
|
|
|
|
|
| |
data.
llvm-svn: 85625
|
|
|
|
| |
llvm-svn: 85621
|
|
|
|
| |
llvm-svn: 85568
|
|
|
|
| |
llvm-svn: 85496
|
|
|
|
| |
llvm-svn: 85449
|
|
|
|
|
|
|
|
|
| |
In the new world order, BlockAddress can have a BasicBlock operand.
This doesn't permute much, because if you have a ConstantExpr (or
anything more specific than Constant) we still know the operand has
to be a Constant.
llvm-svn: 85375
|
|
|
|
|
|
|
| |
readonly section if a reference to the containing function
is valid in the readonly section.
llvm-svn: 85370
|
|
|
|
| |
llvm-svn: 85367
|
|
|
|
|
|
| |
zap BlockAddress values.
llvm-svn: 85366
|
|
|
|
| |
llvm-svn: 85351
|
|
|
|
|
|
|
| |
untested and there is no way to use it, next up: doing battle
with asmparser.
llvm-svn: 85349
|