[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:15:43 PST 2021


aqjune added inline comments.


================
Comment at: llvm/docs/LangRef.rst:2570
+otherwise.
+
 .. _pointeraliasing:
----------------
aqjune wrote:
> 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.
Oh, it was a different story. :/ well, I'll adequately update this part...


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