Page MenuHomePhabricator

[AssumeBundles] Preserve Information from Load/Store

Authored by Tyker on Wed, Mar 25, 2:28 AM.



This patch preserve dereferenceable, nonnull and alignment from loads and stores.

Diff Detail

Event Timeline

Tyker created this revision.Wed, Mar 25, 2:28 AM
Herald added a project: Restricted Project. · View Herald TranscriptWed, Mar 25, 2:28 AM

I love the progress :) Some comments below.

35 ↗(On Diff #252521)

Feel free to commit this as NFC right away.


Let's make this a member function like addCall. We should also merge this with existing logic and put it as a helper somewhere. Given an instruction, and potentially a set of attributes as filter, determine all attributes we can derive from the instruction. I might look into this as the attributor should use that as well to cut down on duplication.


I'd switch on the opcodes, use if-else-if, or early returns.

Tyker updated this revision to Diff 252666.Wed, Mar 25, 2:00 PM
Tyker marked 3 inline comments as done.

fixed comments.


I agree we should try to prevent duplication but we will need to be careful not to be too restrictive about the representation the caller can use such that it can be used widely.

an issue which is hopefully going to get resolved soon. i think this API should reside in Analysis and there are some issues with dependencies for KnowledgeRetention see D76149#inline-701084 for details.

I only have coding style comments left. Providing the logic in a more general way will be future work.


We can have non pointer attributes (later).
+V or Val
(Then we'll also need to rename setPointer)


The above two lines is T, isn't it?


Style: TBH, I'm not necessarily a fan of the overloading via lambda idea. Couldn't we pass all necessary information to addLoadOrStore. I mean, we make it addAccessedPtr(Instruction &Inst, Value &Ptr, Type &AccTy, MaybeAlign Alignment)
and pass the appropriate values.

Tyker updated this revision to Diff 253340.EditedSat, Mar 28, 6:37 AM
Tyker marked 4 inline comments as done.

addressed comments


setPointer is just the function from PointerIntPair, Pointer isn't associated with the llvm type of the Value* but the actual C++ type.


they aren't the same, MemInst->getPointerOperand()->getType() is usually a pointer on the type of T.

One last question


I wonder if we have to guard the nonnull stuff with DerefSize != 0. This is only needed if we have "no-op" 0-length accesses, I think. I doubt those exist. Wdyt?

Tyker marked an inline comment as done.Tue, Mar 31, 7:40 AM
Tyker added inline comments.

i have not seen an example where DerefSize is 0 but since we obtain a minimum size it wouldn't surprise me if it did exist.
if you think it is fine without the check i can remove it.

jdoerfert accepted this revision.Tue, Mar 31, 7:58 AM



Your right, it seems unlikely. Let's keep it like this.

This revision is now accepted and ready to land.Tue, Mar 31, 7:58 AM
This revision was automatically updated to reflect the committed changes.