[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