Johannes Doerfert via llvm-dev
2021-Feb-19 19:35 UTC
[llvm-dev] Confusions around nocapture and sret
1) I don't think so. sret is an attribute for *arguments* that declares they were created from source language return values, it's not a return value attribute. 2) I believe sret shuould imply nocapture when the frontend generates it. So yes. 3) noalias has no direct implications towards nocapture. ~ Johannes On 2/19/21 1:18 PM, Xun Li via llvm-dev wrote:> In the language reference (https://llvm.org/docs/LangRef.html), in the > definition of nocapture, it says "This is not a valid attribute for > return values". However I have seen it often that nocapture comes > together with sret attribute: > https://github.com/llvm/llvm-project/search?q=noalias+nocapture+sret > > A few questions: > 1. Is the LangRef out-of-date for sret+nocapture? > 2. Is an sret argument to a function guaranteed to be nocapture? (i.e. > a pointer cannot escape through a sret argument?) > 3. What about sret+noalias? Is that guaranteed to be nocapture?
If sret implies nocapture, should we modify CallBase::doesNotCapture(unsigned OpNo) to include this case? Currently it only checks whether it has nocapture attribute. On Fri, Feb 19, 2021 at 11:35 AM Johannes Doerfert <johannesdoerfert at gmail.com> wrote:> > 1) I don't think so. sret is an attribute for *arguments* that declares > they were created from source language return values, it's not a return > value attribute. > > 2) I believe sret shuould imply nocapture when the frontend generates > it. So yes. > > 3) noalias has no direct implications towards nocapture. > > ~ Johannes > > > On 2/19/21 1:18 PM, Xun Li via llvm-dev wrote: > > In the language reference (https://llvm.org/docs/LangRef.html), in the > > definition of nocapture, it says "This is not a valid attribute for > > return values". However I have seen it often that nocapture comes > > together with sret attribute: > > https://github.com/llvm/llvm-project/search?q=noalias+nocapture+sret > > > > A few questions: > > 1. Is the LangRef out-of-date for sret+nocapture? > > 2. Is an sret argument to a function guaranteed to be nocapture? (i.e. > > a pointer cannot escape through a sret argument?) > > 3. What about sret+noalias? Is that guaranteed to be nocapture?-- Xun