ArraySize * ElementSize
ElementSize * ArraySize
ArraySize << log2(ElementSize)
ElementSize << log2(ArraySize)
Refactor isArrayMallocHelper and delete isSafeToGetMallocArraySize, so that there is only 1 copy of the malloc array determining logic.
Update users of getMallocArraySize() to not bother calling isArrayMalloc() as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85421 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85375 91177308-0d34-0410-b5e6-96231b3b80d8
Chris claims we should never have visibility_hidden inside any .cpp file but
that's still not true even after this commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85042 91177308-0d34-0410-b5e6-96231b3b80d8
Update all analysis passes and transforms to treat free calls just like FreeInst.
Remove RaiseAllocations and all its tests since FreeInst no longer needs to be raised.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84987 91177308-0d34-0410-b5e6-96231b3b80d8
Update testcases that rely on malloc insts being present.
Also prematurely remove MallocInst handling from IndMemRemoval and RaiseAllocations to help pass tests in this incremental step.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84292 91177308-0d34-0410-b5e6-96231b3b80d8
identifying the malloc as a non-array malloc. This broke GlobalOpt's optimization of stores of mallocs
to global variables.
The fix is to classify malloc's into 3 categories:
1. non-array mallocs
2. array mallocs whose array size can be determined
3. mallocs that cannot be determined to be of type 1 or 2 and cannot be optimized
getMallocArraySize() returns NULL for category 3, and all users of this function must avoid their
malloc optimization if this function returns NULL.
Eventually, currently unexpected codegen for computing the malloc's size argument will be supported in
isArrayMalloc() and getMallocArraySize(), extending malloc optimizations to those examples.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84199 91177308-0d34-0410-b5e6-96231b3b80d8
constants used in inlining heuristics (especially
those used in more than one file). No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83675 91177308-0d34-0410-b5e6-96231b3b80d8
and that will make Caller too big to inline, see if it
might be better to inline Caller into its callers instead.
This situation is described in PR 2973, although I haven't
tried the specific case in SPASS.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83602 91177308-0d34-0410-b5e6-96231b3b80d8
argpromote to avoid invalidating an iterator. This fixes PR4977.
All clang tests now pass with expensive checking (on my system
at least).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81843 91177308-0d34-0410-b5e6-96231b3b80d8
within the notional bounds of the static type of the getelementptr (which
is not the same as "inbounds") from GlobalOpt into a utility routine,
and use it in ConstantFold.cpp to check whether there are any mis-behaved
indices.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81478 91177308-0d34-0410-b5e6-96231b3b80d8
compile-time constant integers or that are out of bounds for their
corresponding static array types. These can cause aliasing that
GlobalOpt assumes won't happen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81165 91177308-0d34-0410-b5e6-96231b3b80d8
an aggregate store overlapping a different aggregate store, despite
the stores having distinct addresses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81164 91177308-0d34-0410-b5e6-96231b3b80d8
is missing the inbounds flag. This is slightly conservative, but it
avoids problems with two constants pointing to the same address but
getting distinct entries in the Memory DenseMap.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81163 91177308-0d34-0410-b5e6-96231b3b80d8
for sanity. This didn't turn up any bugs.
Change CallGraphNode to maintain its "callsite" information in the
call edges list as a WeakVH instead of as an instruction*. This fixes
a broad class of dangling pointer bugs, and makes CallGraph have a number
of useful invariants again. This fixes the class of problem indicated
by PR4029 and PR3601.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80663 91177308-0d34-0410-b5e6-96231b3b80d8
instead of CallGraphNode*'s. This also papers over a callgraph
problem where a pass (in this case, MemCpyOpt) introduces a new
function into the module (llvm.memset.i64) but doesn't add it to
the call graph (nor should it, since it is a function pass).
While it might be a good idea for MemCpyOpt to not synthesize
functions in a runOnFunction(), there is no need for FunctionAttrs
to be boneheaded, so fix it there. This fixes an assertion building
176.gcc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80535 91177308-0d34-0410-b5e6-96231b3b80d8
indirect function pointer, inline it, then go to delete the body.
The problem is that the callgraph had other references to the function,
though the inliner had no way to know it, so we got a dangling pointer
and an invalid iterator out of the deal.
The fix to this is pretty simple: stop the inliner from deleting the
function by knowing that there are references to it. Do this by making
CallGraphNodes contain a refcount. This requires moving deletion of
available_externally functions to the module-level cleanup sweep where
it belongs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80533 91177308-0d34-0410-b5e6-96231b3b80d8
argpromotion and structretpromote. Basically, when replacing
a function, they used the 'changeFunction' api which changes
the entry in the function map (and steals/reuses the callgraph
node).
This has some interesting effects: first, the problem is that it doesn't
update the "callee" edges in any callees of the function in the call graph.
Second, this covers for a major problem in all the CGSCC pass stuff, which
is that it is completely broken when functions are deleted if they *don't*
reuse a CGN. (there is a cute little fixme about this though :).
This patch changes the protocol that CGSCC passes must obey: now the CGSCC
pass manager copies the SCC and preincrements its iterator to avoid passes
invalidating it. This allows CGSCC passes to mutate the current SCC. However
multiple passes may be run on that SCC, so if passes do this, they are now
required to *update* the SCC to be current when they return.
Other less interesting parts of this patch are that it makes passes update
the CG more directly, eliminates changeFunction, and requires clients of
replaceCallSite to specify the new callee CGN if they are changing it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80527 91177308-0d34-0410-b5e6-96231b3b80d8
calls into a function and if the calls bring in arrays, try to merge
them together to reduce stack size. For example, in the testcase
we'd previously end up with 4 allocas, now we end up with 2 allocas.
As described in the comments, this is not really the ideal solution
to this problem, but it is surprisingly effective. For example, on
176.gcc, we end up eliminating 67 arrays at "gccas" time and another
24 at "llvm-ld" time.
One piece of concern that I didn't look into: at -O0 -g with
forced inlining this will almost certainly result in worse debug
info. I think this is acceptable though given that this is a case
of "debugging optimized code", and we don't want debug info to
prevent the optimizer from doing things anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80215 91177308-0d34-0410-b5e6-96231b3b80d8
and introduce a new Instruction::isIdenticalTo which tests for full
identity, including the SubclassOptionalData flags. Also, fix the
Instruction::clone implementations to preserve the SubclassOptionalData
flags. Finally, teach several optimizations how to handle
SubclassOptionalData correctly, given these changes.
This fixes the counterintuitive behavior of isIdenticalTo not comparing
the full value, and clone not returning an identical clone, as well as
some subtle bugs that could be caused by these.
Thanks to Nick Lewycky for reporting this, and for an initial patch!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80038 91177308-0d34-0410-b5e6-96231b3b80d8
This change speeds up llvm-gcc by more then 6% at "-O0 -g" (measured by compiling InstructionCombining.cpp!)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79977 91177308-0d34-0410-b5e6-96231b3b80d8
the command line. This gives llvm-gcc developers
a way to control inlining (documented as "not intended
for end users").
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79966 91177308-0d34-0410-b5e6-96231b3b80d8
member out of line. ftostr is not particularly speedy,
so that method is presumably not perf sensitive.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79885 91177308-0d34-0410-b5e6-96231b3b80d8
by hand, and fix a few places that were using hasInitializer() that
appear to depend on the initializer value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79441 91177308-0d34-0410-b5e6-96231b3b80d8
vector (&Formals[0]). With this change llvm-gcc builds
with expensive checking enabled for C, C++ and Fortran.
While there, change a std::vector into a SmallVector.
This is partly gratuitous, but mostly because not all
STL vector implementations define the data method (and
it should be faster).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79237 91177308-0d34-0410-b5e6-96231b3b80d8
a Twine, e.g., for names).
- I am a little ambivalent about this; we don't want the string conversion of
utostr, but using overload '+' mixed with string and integer arguments is
sketchy. On the other hand, this particular usage is something of an idiom.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77579 91177308-0d34-0410-b5e6-96231b3b80d8
- Some clients which used DOUT have moved to DEBUG. We are deprecating the
"magic" DOUT behavior which avoided calling printing functions when the
statement was disabled. In addition to being unnecessary magic, it had the
downside of leaving code in -Asserts builds, and of hiding potentially
unnecessary computations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77019 91177308-0d34-0410-b5e6-96231b3b80d8
"private" symbols which the assember shouldn't strip, but which the linker may
remove after evaluation. This is mostly useful for Objective-C metadata.
This is plumbing, so we don't have a use of it yet. More to come, etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76385 91177308-0d34-0410-b5e6-96231b3b80d8
This adds location info for all llvm_unreachable calls (which is a macro now) in
!NDEBUG builds.
In NDEBUG builds location info and the message is off (it only prints
"UREACHABLE executed").
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75640 91177308-0d34-0410-b5e6-96231b3b80d8
Make llvm_unreachable take an optional string, thus moving the cerr<< out of
line.
LLVM_UNREACHABLE is now a simple wrapper that makes the message go away for
NDEBUG builds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75379 91177308-0d34-0410-b5e6-96231b3b80d8
>>
>
> It doesn't matter in terms of semantics: because AnalyzeGlobal
> returned false, we're guaranteed the address of the global is never
> taken. I wouldn't be surprised if we end up generating invalid IR in
> some cases, though, because of the semantics of replaceAllUsesWith.
> Do you have a testcase that breaks?
>
>
The problem is replaceAllUsesWith asserts for type mismatch here. Try attached .bc with llvm-ld.
assert(New->getType() == getType() &&
"replaceAllUses of value with new value of different type!");
Since stack is always on address space zero, I don't think that type of GV in a different address space is ever going to match.
The other way is to allow replaceAllUsesWith to ignore address spaces while comparing types. (do we have a way to do that ?).
But then such an optimization may fail the entire idea of user wanting to place a variable into different memory space. The original idea of user might be to save on the stack space (data memory) and hence he asked the variable to be placed into different memory space (program memory). So the best bet here is to deny this optimization by checking
GV->getType()->getAddressSpace() == 0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73605 91177308-0d34-0410-b5e6-96231b3b80d8
is that, for functions whose bodies are entirely guarded by an if-statement, it
can be profitable to pull the test out of the callee and into the caller.
This code has had some cursory testing, but still has a number of known issues
on the LLVM test suite.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73338 91177308-0d34-0410-b5e6-96231b3b80d8
the relationship with MergeFunctions.cpp's isEquivalentOperation,
and make a trivial code reordering so that the two functions are
easier to compare.
Fix the name of Instruction::isSameOperationAs in MergeFunction.cpp's
isEquivalentOperation's comment, and fix a nearby 80-column violation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73241 91177308-0d34-0410-b5e6-96231b3b80d8
points to while analyzing all other fields.
Use FoldingSetNodeID to produce a good hash. This dramatically decreases run
times.
Emit thunks. This means that it can look at all functions regardless of what
the linkage is or if the address is taken, but unfortunately some small
functions can be even shorter than the thunk because our backend doesn't yet
realize it can just turn these into jumps. This means that this pass will
pessimize code on average.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73222 91177308-0d34-0410-b5e6-96231b3b80d8
identical function ConstantIsDead() to SafeToDestroyConstant(), to
emphasise the connection with Constant::destroyConstant().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73149 91177308-0d34-0410-b5e6-96231b3b80d8
and it wasn't generating calls through @PLT for these functions.
hasLocalLinkage() is now false for available_externally,
I attempted to fix the inliner and dce to handle available_externally properly.
It passed make check.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72328 91177308-0d34-0410-b5e6-96231b3b80d8
the readnone. Since MallocInst is scheduled for deletion
it doesn't seem worth doing anything more subtle, such as
having mayWriteToMemory return true for MallocInst.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71077 91177308-0d34-0410-b5e6-96231b3b80d8
the inliner; prevents nondeterministic behavior
when the same address is reallocated.
Don't build call graph nodes for debug intrinsic calls;
they're useless, and there were typically a lot of them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@67311 91177308-0d34-0410-b5e6-96231b3b80d8
changes.
For InvokeInst now all arguments begin at op_begin().
The Callee, Cont and Fail are now faster to get by
access relative to op_end().
This patch introduces some temporary uglyness in CallSite.
Next I'll bring CallInst up to a similar scheme and then
the uglyness will magically vanish.
This patch also exposes all the reliance of the libraries
on InvokeInst's operand ordering. I am thinking of taking
care of that too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66920 91177308-0d34-0410-b5e6-96231b3b80d8
and extern_weak_odr. These are the same as the non-odr versions,
except that they indicate that the global will only be overridden
by an *equivalent* global. In C, a function with weak linkage can
be overridden by a function which behaves completely differently.
This means that IP passes have to skip weak functions, since any
deductions made from the function definition might be wrong, since
the definition could be replaced by something completely different
at link time. This is not allowed in C++, thanks to the ODR
(One-Definition-Rule): if a function is replaced by another at
link-time, then the new function must be the same as the original
function. If a language knows that a function or other global can
only be overridden by an equivalent global, it can give it the
weak_odr linkage type, and the optimizers will understand that it
is alright to make deductions based on the function body. The
code generators on the other hand map weak and weak_odr linkage
to the same thing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66339 91177308-0d34-0410-b5e6-96231b3b80d8
to find a tiny mouse hole to squeeze through, it struck
me that globals without a name can be considered internal
since they can't be referenced from outside the current
module. This patch makes GlobalOpt give them internal
linkage. Also done for aliases even though they always
have names, since in my opinion anonymous aliases should
be allowed for consistency with global variables and
functions. So if that happens one day, this code is ready!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66267 91177308-0d34-0410-b5e6-96231b3b80d8
If non constant local GV named A is used by a constant local GV named B (e.g. llvm.dbg.variable) and B is not used by anyone else then eliminate A as well as B.
In other words, debug info should not interfere in removal of unused GV.
--This life, and those below, will be ignored--
M test/Transforms/GlobalOpt/2009-03-03-dbg.ll
M lib/Transforms/IPO/GlobalOpt.cpp
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66167 91177308-0d34-0410-b5e6-96231b3b80d8
here. Since we only do the transform if there is
one use, strip off any such users in the hope of
making the transform fire more often.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@64926 91177308-0d34-0410-b5e6-96231b3b80d8
alias can be morphed into the target. Implement this
transform, and fix a crash in the existing transform at
the same time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@64583 91177308-0d34-0410-b5e6-96231b3b80d8
There is now a direct way from value-use-iterator to incoming block in PHINode's API.
This way we avoid the iterator->index->iterator trip, and especially the costly
getOperandNo() invocation. Additionally there is now an assertion that the iterator
really refers to one of the PHI's Uses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62869 91177308-0d34-0410-b5e6-96231b3b80d8
doing very similar pointer capture analysis.
Factor out the common logic. The new version
is from FunctionAttrs since it does a better
job than the version in BasicAliasAnalysis
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62461 91177308-0d34-0410-b5e6-96231b3b80d8
vector and extraneous loop over it, 2) not delete globals used by
phis/selects etc which could actually be useful. This fixes PR3321.
Many thanks to Duncan for narrowing this down.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62201 91177308-0d34-0410-b5e6-96231b3b80d8
compensation for turning off gcc's inliner. This gets
us closer to the amount of inlining we were getting before.
It is not a win on everything, of course, but seems to
gain overall.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62058 91177308-0d34-0410-b5e6-96231b3b80d8
was it not very helpful, it was also wrong! The problem
is shown in the testcase: the alloca might be passed to
a nocapture callee which dereferences it and returns the
original pointer. But because it was a nocapture call we
think we don't need to track its uses, but we do.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61876 91177308-0d34-0410-b5e6-96231b3b80d8
In fact this also deletes those with linkonce linkage,
however this is currently dead because for the moment
aliases aren't allowed to have this linkage type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61742 91177308-0d34-0410-b5e6-96231b3b80d8
not have pointer type. In particular, it may
be the condition argument for a select or a GEP
index. While I was unable to construct a testcase
for which some bits of the original pointer are
captured due to one of these, it's very very close
to being possible - so play safe and exclude these
possibilities.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61580 91177308-0d34-0410-b5e6-96231b3b80d8
the argument to be stored to an alloca by tracking uses
of the alloca. This occurs 4 times (out of 7121, 0.05%)
in MultiSource/Applications, so may not be worth it. On
the other hand, it is easy to do and fairly cheap. The
functions it helps are: W_addcom and W_addlit in spiff;
process_args (argv) in d (make_dparser); ercPixConcealIMB
in JM/ldecod.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61570 91177308-0d34-0410-b5e6-96231b3b80d8
functions that don't write can't leak a pointer except through
the return value, so a void readonly function is implicitly nocapture.
Test these, and add a test that verifies that f1 calling f2 with an
otherwise dead pointer gets both of them marked nocapture.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61552 91177308-0d34-0410-b5e6-96231b3b80d8
to work out (in a very simplistic way) which function
arguments (pointer arguments only) are only dereferenced
and so do not escape. Mark such arguments 'nocapture'.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61525 91177308-0d34-0410-b5e6-96231b3b80d8
and select instructions doesn't buy anything here
except extra complexity: the only difference in
the entire testsuite was that a readonly function
became readnone in MiBench/consumer-typeset. Add
a comment about this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61478 91177308-0d34-0410-b5e6-96231b3b80d8
constants, since doing so is irrelevant for aliasing
purposes. While this doesn't increase the total number
of functions marked readonly or readnone in MultiSource/
Applications (3089), it does result in 12 functions being
marked readnone rather than readonly.
Before:
readnone: 820
readonly: 2269
After:
readnone: 832
readonly: 2257
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61469 91177308-0d34-0410-b5e6-96231b3b80d8
nodes. This allows it to do fairly general phi insertion if a
load from a pointer global wants to be SRAd but the load is used
by (recursive) phi nodes. This fixes a pessimization on ppc
introduced by Load PRE.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61123 91177308-0d34-0410-b5e6-96231b3b80d8
* merge two weak functions by making them both alias a third non-weak fn
* don't reimplement CallSite::hasArgument
* whitelist the safe linkage types
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58568 91177308-0d34-0410-b5e6-96231b3b80d8
This triggers only 60 times in llvm-test (look at .llvm.bc, not .linked.rbc)
and so it probably wont be turned on by default. Also, may of those are likely
to go away when PR2973 is fixed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58557 91177308-0d34-0410-b5e6-96231b3b80d8
function.
- This explicitly models the costs for functions which should
"always" or "never" be inlined. This fixes bugs where such costs
were not previously respected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58450 91177308-0d34-0410-b5e6-96231b3b80d8
when deciding whether to mark a function readnone/readonly.
Since the pass is currently run before SROA, this may be
quite helpful. Requested by Chris on IRC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57050 91177308-0d34-0410-b5e6-96231b3b80d8
- return attributes - inreg, zext and sext
- parameter attributes
- function attributes - nounwind, readonly, readnone, noreturn
Return attributes use 0 as the index.
Function attributes use ~0U as the index.
This patch requires corresponding changes in llvm-gcc and clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56704 91177308-0d34-0410-b5e6-96231b3b80d8
s/ParamAttr/Attribute/g
s/PAList/AttrList/g
s/FnAttributeWithIndex/AttributeWithIndex/g
s/FnAttr/Attribute/g
This sets the stage
- to implement function notes as function attributes and
- to distinguish between function attributes and return value attributes.
This requires corresponding changes in llvm-gcc and clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56622 91177308-0d34-0410-b5e6-96231b3b80d8
can get the readnone/readonly attributes, and gives them it.
The plan is to remove markmodref (which did the same thing
by querying GlobalsModRef) and delete the analogous
functionality from GlobalsModRef.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56341 91177308-0d34-0410-b5e6-96231b3b80d8
call (thus changing the call site) it didn't
inform the callgraph about this. But the
call site does matter - as shown by the testcase,
the callgraph become invalid after the inliner
ran (with an edge between two functions simply
missing), resulting in wrong deductions by
GlobalsModRef.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55872 91177308-0d34-0410-b5e6-96231b3b80d8
because it does not maintain a correct list
of callsites. I discovered (see following
commit) that the inliner will create a wrong
callgraph if it is fed a callgraph with
correct edges but incorrect callsites. These
were created by Prune-EH, and while it wasn't
done via removeCallEdgeTo, it could have been
done via removeCallEdgeTo, which is an accident
waiting to happen. Use removeCallEdgeFor
instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55859 91177308-0d34-0410-b5e6-96231b3b80d8
invalidating the iterator by deleting the current use. This fixes a segfault on
64 bit linux reported in PR2675.
Also remove an unneeded if.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54778 91177308-0d34-0410-b5e6-96231b3b80d8
that says "unconditional loads from this argument are safe", we now keep track
of the safety per set of indices from which loads happen. This prevents
ArgPromotion from promoting loads that aren't really valid. As an added effect,
this will now disregard the the type of the indices passed to a GEP, so
"load GEP %A, i32 1" and "load GEP %A, i64 1" will result in a single argument,
not two.
This fixes PR2598, for which a testcase has been added as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54159 91177308-0d34-0410-b5e6-96231b3b80d8
Remove the GetResultInst instruction. It is still accepted in LLVM assembly
and bitcode, where it is now auto-upgraded to ExtractValueInst. Also, remove
support for return instructions with multiple values. These are auto-upgraded
to use InsertValueInst instructions.
The IRBuilder still accepts multiple-value returns, and auto-upgrades them
to InsertValueInst instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53941 91177308-0d34-0410-b5e6-96231b3b80d8
return value as a whole in deadargelim is really not needed now that we simply
rebuild the old return value and actually prevents some canonicalization from
taking place.
This revert stops deadargelim from changing {i32} into i32 for now, but I'll
fix that next.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53609 91177308-0d34-0410-b5e6-96231b3b80d8
return values that are still (partially) live. Instead of updating all uses of
a call instruction after removing some elements, it now just rebuilds the
original struct (With undef gaps where the unused values were) and leaves it to
instcombine to clean this up.
The added testcase still fails currently, but this is due to instcombine which
isn't good enough yet. I will fix that part next.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53608 91177308-0d34-0410-b5e6-96231b3b80d8
only the liveness of partial return values (for functions returning a struct).
This is more explicit to prevent unwanted changes in the return value.
In particular, deadargelim now canonicalizes a function returning {i32} to
returning i32 and {} to void, if the struct returned is not used in its
entirety, but only the single element is used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53606 91177308-0d34-0410-b5e6-96231b3b80d8
and return values live for those functions. This doesn't change anything yet,
but prepares for the coming commits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53601 91177308-0d34-0410-b5e6-96231b3b80d8
Rewrite the DeadArgumentElimination pass, to use a more explicit tracking of
dependencies between return values and/or arguments. Also make the handling of
arguments and return values the same.
The pass now looks properly inside returned structs, but only at the first
level (ie, not inside nested structs).
This version fixed a few more bugs and was cleaned up a bit. It now passes all
of LLVM's testing, and should still pass SPEC2006. There is still a minor bug
with regard to returning nested structs. Since there is currently nothing that
emits such IR, I will fix that in a seperate commit (partly because it requires
a non-trivial fix).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53400 91177308-0d34-0410-b5e6-96231b3b80d8
DeadArgumentElimination and assert that the function type does not change if
nothing was changed. This should catch subtle changes in function type that are
not intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52536 91177308-0d34-0410-b5e6-96231b3b80d8
This is a fixed version that no longer uses multimap::equal_range, which
resulted in a pointer invalidation problem.
Also, DAE::InspectedFunctions was not really necessary, so it got removed.
Lastly, this version no longer applies the extra arg hack on functions who did
not have any arguments to start with.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52532 91177308-0d34-0410-b5e6-96231b3b80d8
dependencies between return values and/or arguments. Also make the handling of
arguments and return values the same.
The pass now looks properly inside returned structs, but only at the first
level (ie, not inside nested structs).
Also add a testcase for testing various variations of (multiple) dead rerturn
values.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52459 91177308-0d34-0410-b5e6-96231b3b80d8
time. Sorry for the trouble!
This time, also add a testcase, which I should have done in the first place...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52455 91177308-0d34-0410-b5e6-96231b3b80d8
speaking these are not constant values. However, when a function always returns
one of its arguments, then from the point of view of each caller the return
value is constant (or at least a known value) and can be replaced.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52397 91177308-0d34-0410-b5e6-96231b3b80d8
individually.
Also learn IPConstProp how returning first class aggregates work, in addition
to old style multiple return instructions.
Modify the return-constants testscase to confirm this behaviour.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52396 91177308-0d34-0410-b5e6-96231b3b80d8
the section or the visibility from one global
value to another: copyAttributesFrom. This is
particularly useful for duplicating functions:
previously this was done by explicitly copying
each attribute in turn at each place where a
new function was created out of an old one, with
the result that obscure attributes were regularly
forgotten (like the collector or the section).
Hopefully now everything is uniform and nothing
is forgotten.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51567 91177308-0d34-0410-b5e6-96231b3b80d8
replaced at linktime with a body that throws, even
if the body in this file does not. Make PruneEH
be more conservative in this case.
g++.dg/eh/weak1.C
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51207 91177308-0d34-0410-b5e6-96231b3b80d8
several things that were neither in an anonymous namespace nor static
but not intended to be global.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51017 91177308-0d34-0410-b5e6-96231b3b80d8
a FunctionPass. This makes it simpler, fixes dozens of bugs, adds
a couple of minor features, and shrinks is considerably: from
2214 to 1437 lines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@50520 91177308-0d34-0410-b5e6-96231b3b80d8
generalizes the previous code to handle the case when the string is not
an immediate to the strlen call (for example, crazy stuff like
strlen(c ? "foo" : "bart"+1) -> 3). This implements
gcc.c-torture/execute/builtins/strlen-2.c. I will generalize other
cases in simplifylibcalls to use the same routine later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@50408 91177308-0d34-0410-b5e6-96231b3b80d8
appropriate alignment. This fixes a miscompilation of 252.eon on
x86-64 (rdar://5891920).
Bill, please pull this into Tak.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@50308 91177308-0d34-0410-b5e6-96231b3b80d8
Specifically, introduction of XXX::Create methods
for Users that have a potentially variable number of
Uses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49277 91177308-0d34-0410-b5e6-96231b3b80d8
2. Do not use # of basic blocks as part of the cost computation since it doesn't really figure into function size.
3. More aggressively inline function with vector code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49061 91177308-0d34-0410-b5e6-96231b3b80d8
Furthermore, double the limit when more than 10% of the callee instructions are vector instructions. Multimedia kernels tend to love inlining.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@48725 91177308-0d34-0410-b5e6-96231b3b80d8
1. There is now a "PAListPtr" class, which is a smart pointer around
the underlying uniqued parameter attribute list object, and manages
its refcount. It is now impossible to mess up the refcount.
2. PAListPtr is now the main interface to the underlying object, and
the underlying object is now completely opaque.
3. Implementation details like SmallVector and FoldingSet are now no
longer part of the interface.
4. You can create a PAListPtr with an arbitrary sequence of
ParamAttrsWithIndex's, no need to make a SmallVector of a specific
size (you can just use an array or scalar or vector if you wish).
5. All the client code that had to check for a null pointer before
dereferencing the pointer is simplified to just access the
PAListPtr directly.
6. The interfaces for adding attrs to a list and removing them is a
bit simpler.
Phase #2 will rename some stuff (e.g. PAListPtr) and do other less
invasive changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@48289 91177308-0d34-0410-b5e6-96231b3b80d8
This pass transforms
%struct._Point = type { i32, i32, i32, i32, i32, i32 }
define internal void @foo(%struct._Point* sret %agg.result)
into
%struct._Point = type { i32, i32, i32, i32, i32, i32 }
define internal %struct._Point @foo()
This pass updates foo() clients appropriately to use
getresult instruction to extract return values.
This pass is not yet ready for prime time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47776 91177308-0d34-0410-b5e6-96231b3b80d8
for adding alignment info, not there yet). Clean up
interfaces to reference ParameterAttributes consistently.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47342 91177308-0d34-0410-b5e6-96231b3b80d8
requested by Chris. While there, do the same
for an existing function committed by someone
called "lattner" :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47273 91177308-0d34-0410-b5e6-96231b3b80d8
promoted functions. This is important for varargs calls in
particular. Thanks to duncan for providing a great testcase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46108 91177308-0d34-0410-b5e6-96231b3b80d8
byval work. This miscompilation is due to the program indexing an array out
of range and us doing a transformation that broke this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45949 91177308-0d34-0410-b5e6-96231b3b80d8
get away with it, which exposes opportunities to eliminate the memory
objects entirely. For example, we now compile byval.ll to:
define internal void @f1(i32 %b.0, i64 %b.1) {
entry:
%tmp2 = add i32 %b.0, 1 ; <i32> [#uses=0]
ret void
}
define i32 @main() nounwind {
entry:
call void @f1( i32 1, i64 2 )
ret i32 0
}
This seems like it would trigger a lot for code that passes around small
structs (e.g. SDOperand's or _Complex)...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45886 91177308-0d34-0410-b5e6-96231b3b80d8
direct calls bails out unless caller and callee have essentially
equivalent parameter attributes. This is illogical - the callee's
attributes should be of no relevance here. Rework the logic, which
incidentally fixes a crash when removed arguments have attributes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45658 91177308-0d34-0410-b5e6-96231b3b80d8
return attributes on the floor. In the case of a call
to a varargs function where the varargs arguments are
being removed, any call attributes on those arguments
need to be dropped. I didn't do this because I plan to
make it illegal to have such attributes (see next patch).
With this change, compiling the gcc filter2 eh test at -O0
and then running opt -std-compile-opts on it results in
a correctly working program (compiling at -O1 or higher
results in the test failing due to a problem with how we
output eh info into the IR).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45285 91177308-0d34-0410-b5e6-96231b3b80d8
calls 'nounwind'. It is important for correct C++
exception handling that nounwind markings do not get
lost, so this transformation is actually needed for
correctness.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45218 91177308-0d34-0410-b5e6-96231b3b80d8
throw exceptions", just mark intrinsics with the nounwind
attribute. Likewise, mark intrinsics as readnone/readonly
and get rid of special aliasing logic (which didn't use
anything more than this anyway).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44544 91177308-0d34-0410-b5e6-96231b3b80d8
the function type, instead they belong to functions
and function calls. This is an updated and slightly
corrected version of Reid Spencer's original patch.
The only known problem is that auto-upgrading of
bitcode files doesn't seem to work properly (see
test/Bitcode/AutoUpgradeIntrinsics.ll). Hopefully
a bitcode guru (who might that be? :) ) will fix it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44359 91177308-0d34-0410-b5e6-96231b3b80d8
from a file containing Function/BasicBlock pairings. This is not safe against
anonymous or abnormally-named Funcs or BBs.
Make bugpoint use this interface to pass the BBs list to the child bugpoint.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44101 91177308-0d34-0410-b5e6-96231b3b80d8
The meaning of getTypeSize was not clear - clarifying it is important
now that we have x86 long double and arbitrary precision integers.
The issue with long double is that it requires 80 bits, and this is
not a multiple of its alignment. This gives a primitive type for
which getTypeSize differed from getABITypeSize. For arbitrary precision
integers it is even worse: there is the minimum number of bits needed to
hold the type (eg: 36 for an i36), the maximum number of bits that will
be overwriten when storing the type (40 bits for i36) and the ABI size
(i.e. the storage size rounded up to a multiple of the alignment; 64 bits
for i36).
This patch removes getTypeSize (not really - it is still there but
deprecated to allow for a gradual transition). Instead there is:
(1) getTypeSizeInBits - a number of bits that suffices to hold all
values of the type. For a primitive type, this is the minimum number
of bits. For an i36 this is 36 bits. For x86 long double it is 80.
This corresponds to gcc's TYPE_PRECISION.
(2) getTypeStoreSizeInBits - the maximum number of bits that is
written when storing the type (or read when reading it). For an
i36 this is 40 bits, for an x86 long double it is 80 bits. This
is the size alias analysis is interested in (getTypeStoreSize
returns the number of bytes). There doesn't seem to be anything
corresponding to this in gcc.
(3) getABITypeSizeInBits - this is getTypeStoreSizeInBits rounded
up to a multiple of the alignment. For an i36 this is 64, for an
x86 long double this is 96 or 128 depending on the OS. This is the
spacing between consecutive elements when you form an array out of
this type (getABITypeSize returns the number of bytes). This is
TYPE_SIZE in gcc.
Since successive elements in a SequentialType (arrays, pointers
and vectors) need to be aligned, the spacing between them will be
given by getABITypeSize. This means that the size of an array
is the length times the getABITypeSize. It also means that GEP
computations need to use getABITypeSize when computing offsets.
Furthermore, if an alloca allocates several elements at once then
these too need to be aligned, so the size of the alloca has to be
the number of elements multiplied by getABITypeSize. Logically
speaking this doesn't have to be the case when allocating just
one element, but it is simpler to also use getABITypeSize in this
case. So alloca's and mallocs should use getABITypeSize. Finally,
since gcc's only notion of size is that given by getABITypeSize, if
you want to output assembler etc the same as gcc then getABITypeSize
is the size you want.
Since a store will overwrite no more than getTypeStoreSize bytes,
and a read will read no more than that many bytes, this is the
notion of size appropriate for alias analysis calculations.
In this patch I have corrected all type size uses except some of
those in ScalarReplAggregates, lib/Codegen, lib/Target (the hard
cases). I will get around to auditing these too at some point,
but I could do with some help.
Finally, I made one change which I think wise but others might
consider pointless and suboptimal: in an unpacked struct the
amount of space allocated for a field is now given by the ABI
size rather than getTypeStoreSize. I did this because every
other place that reserves memory for a type (eg: alloca) now
uses getABITypeSize, and I didn't want to make an exception
for unpacked structs, i.e. I did it to make things more uniform.
This only effects structs containing long doubles and arbitrary
precision integers. If someone wants to pack these types more
tightly they can always use a packed struct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43620 91177308-0d34-0410-b5e6-96231b3b80d8
miscompilation of 188.ammp. Reject select and bitcast in
ValueIsOnlyUsedLocallyOrStoredToOneGlobal because RewriteHeapSROALoadUser can't handle it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41950 91177308-0d34-0410-b5e6-96231b3b80d8
a limited form of PHI nodes. This finally fixes PR1639, speeding 179.art up
from 7.84s to 3.13s on PPC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41933 91177308-0d34-0410-b5e6-96231b3b80d8
Use APFloat in UpgradeParser and AsmParser.
Change all references to ConstantFP to use the
APFloat interface rather than double. Remove
the ConstantFP double interfaces.
Use APFloat functions for constant folding arithmetic
and comparisons.
(There are still way too many places APFloat is
just a wrapper around host float/double, but we're
getting there.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41747 91177308-0d34-0410-b5e6-96231b3b80d8
This interface allows clients to inline bunch of functions with module
level call graph information.:wq
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@40486 91177308-0d34-0410-b5e6-96231b3b80d8
Due to darwin gcc bug, one version of darwin linker coalesces
static const int, which defauts PassID based pass identification.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@36652 91177308-0d34-0410-b5e6-96231b3b80d8
printf("") -> noop. Still need to do the xforms for fprintf.
This implements Transforms/SimplifyLibCalls/Printf.ll
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@35984 91177308-0d34-0410-b5e6-96231b3b80d8
as its main datastructure. There are many improvements yet to be made, but
this speeds up opt --std-compile-opts on 447.dealII by 7.3%.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34193 91177308-0d34-0410-b5e6-96231b3b80d8
This happened because deadargelim now causes VMCore to auto-rename every
function that it hacks arguments out of. Because it hacks arguments out of
functions in a non-deterministic order, this caused the resultant numbering
to be nondet. The fix is to just be careful to not rename functions!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34005 91177308-0d34-0410-b5e6-96231b3b80d8
the Transforms library. This reduces debug library size by 132 KB, debug
binary size by 376 KB, and reduces link time for llvm tools slightly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33939 91177308-0d34-0410-b5e6-96231b3b80d8
This patch replaces the SymbolTable class with ValueSymbolTable which does
not support types planes. This means that all symbol names in LLVM must now
be unique. The patch addresses the necessary changes to deal with this and
removes code no longer needed as a result. This completes the bulk of the
changes for this PR. Some cleanup patches will follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33918 91177308-0d34-0410-b5e6-96231b3b80d8
This feature is needed in order to support shifts of more than 255 bits
on large integer types. This changes the syntax for llvm assembly to
make shl, ashr and lshr instructions look like a binary operator:
shl i32 %X, 1
instead of
shl i32 %X, i8 1
Additionally, this should help a few passes perform additional optimizations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33776 91177308-0d34-0410-b5e6-96231b3b80d8
