[llvm-commits] [llvm] r90045 - in /llvm/trunk: lib/Analysis/MemoryDependenceAnalysis.cpp test/Transforms/DeadStoreElimination/lifetime.ll

Chris Lattner clattner at apple.com
Fri Dec 4 21:58:12 PST 2009


On Dec 2, 2009, at 12:36 AM, Duncan Sands wrote:

> Hi Chris,
> 
>> mustalias queries don't care about the size of the operands, so  getting it is pointless.  Either the pointers themselves mustalias or  not.  As such, this won't catch the case where you have a lifetime  marker saying that a 20 byte object is live/dead but where you're  accessing 4 bytes into the 20 byte object.  I don't know if you care  about this case, if so, please fix it somehow, otherwise remove the  dead code and add a FIXME describing the issue.
> 
> I don't know if the following use case is relevant to this, but since it's
> important to me I mention it here: the dragonegg trampoline code creates a
> struct alloca for which one field (holding the trampoline pointer)] is constant
> after being initialized.  For technical reasons (i.e. this was the best I could
> come up with given that I can't modify gcc itself) this field is in the middle
> of the alloca, and other fields are not constant.  I mark this field with an llvm.invariant call.  It is important that loads from this field simplify to the
> original stored value whenever possible, since this can result in eliminating
> uses of the trampoline (a big win).  [Such loads may be in other functions and
> as such only exposed after inlining].  Currently such loads are not always
> simplified :(  This is an example where the whole object is not invariant, and
> it is important to be precise about what is being accessed.

I think the current code should be capable of getting this. The start of the invariant field and the start of the invariant call should mustalias.  Do you have a simple testcase that shows this?

-Chris



More information about the llvm-commits mailing list