[PATCH] D94002: [LangRef] Make lifetime intrinsic's semantics consistent with StackColoring's comment

Juneyoung Lee via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 5 18:11:06 PST 2021


aqjune added inline comments.


================
Comment at: llvm/docs/LangRef.rst:2570
+otherwise.
+
 .. _pointeraliasing:
----------------
jdoerfert wrote:
> aqjune wrote:
> > jdoerfert wrote:
> > > Is "preserved" the right word here? Maybe "reserved"?
> > > 
> > > ---
> > > 
> > > _ "allocation instruction"
> > > + "allocation value"
> > > 
> > > or something else because globals are not instructions.
> > > 
> > > ---
> > > 
> > > _ "returns"
> > > + "return"
> > > 
> > > ---
> > > 
> > > _ "free-like commands" 
> > > + instructions that deallocate the object or impact it's lifetime
> > > 
> > > ---
> > > 
> > > Lifetime markers, as of now, still talk about memory regions, not objects. I think that can be changed but should be kept in mind.
> > > 
> > > ---
> > > 
> > > Why the "representable in integers" part, and "integral address"?
> > > 
> > Thanks.
> > 
> > > Why the "representable in integers" part, and "integral address"?
> > 
> > Because it is important (IMO) and related to the lifetime. To be specific this patch, It answers whether two stack allocas with different lifetimes may have overlapping addresses.
> I can compare two pointers without converting them to integers, can't I? If so, I don't understand in which situations this special case would be applied. Said differently: When not convertable to integers and not comparable, and why shouldn't lifetime apply then?
While answering to your mail, I think I understood your point. If the memory block is never observed, it doesn't matter whether it is disjoint or not.
I'll update the text.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94002/new/

https://reviews.llvm.org/D94002



More information about the llvm-commits mailing list