search for: safetospecul

...y executed (same as notrap?) > Isn't this already true of all instructions? Unless we can *prove* that speculating an instruction can't introduce faults, we can't speculate it ever. An unknown call or intrinsic should already have this property right? Possibly? We probably need a safetospeculate attribute, then. > > This part of the proposal doesn't feel mature to me. In particular, I think we need to talk about what other cases we want to handle w.r.t. speculation attributes and what our model is. > > One case I want to support is for small functions which only read...

...t likes. I'll gladly submit a patch that uses these hints, but I'd like to reach some consensus on what the desired attributes actually are first. The last thing I want is to add attributes that are only useful to myself. Regarding having several orthogonal attributes vs. things like "safetospeculate": To know a function is safe to speculatively execute, I need at least: 1) readnone (readonly is insufficient, unless I know all accessed pointers are valid) 2) nounwind 3) nolongjmp (I guess?) 4) no undefined behavior. This includes things like "halting" and "no division by...

..." as Nick suggested, for the lack of other options. If the name stays I'll add it to the documentation.) Regarding auditing the intrinsics - I'd prefer to do this in stages. Here I'm just preserving the current behavior by marking intrinsics that used to be explicitly handled in isSafeToSpeculativelyExecute(), so there should be no functional change. From: Nick Lewycky [mailto:nlewycky at google.com] Sent: Tuesday, July 23, 2013 02:29 To: Kuperstein, Michael M Cc: Nick Lewycky; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Does nounwind have semantics? On 22 July 2013 01:11, Kuperstein...

...it a > patch that uses these hints, but I'd like to reach some consensus on what > the desired attributes actually are first. The last thing I want is to add > attributes that are only useful to myself. > > Regarding having several orthogonal attributes vs. things like > "safetospeculate": > > To know a function is safe to speculatively execute, I need at least: > 1) readnone (readonly is insufficient, unless I know all accessed pointers > are valid) > 2) nounwind > 3) nolongjmp (I guess?) > 4) no undefined behavior. This includes things like "halt...

Kuperstein, Michael M wrote: > A patch is attached. + const CallInst* CI = dyn_cast<CallInst>(Inst); + return CI->isSafeToSpeculativelyExecute(); "return cast<CallInst>(Inst)->isSafeToSpeculativelyExecute();"? Use cast<> instead of dyn_cast<>. See http://llvm.org/docs/ProgrammersManual.html#isa . Then I don't think it needs to be two lines. You can even remove the extra curly braces aro...

...ly+halting+nounwind+nolongjmp is going to be common and I'd feel silly if we had a special case for readnone+halting+nounwind+nolongjmp and thus couldn't optimize the more common case. That said, I'm also going to feel silly if we don't end up with enough attributes to allow isSafeToSpeculate to deduce it, which is where we are right now. I was planning to get back to fixing this after Chandler's promised PassManager work. Nick > > Michael > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of...

...2:11 To: Kuperstein, Michael M Cc: Nick Lewycky; llvmdev at cs.uiuc.edu; Tobias Grosser; echristo at gmail.com Subject: Re: [LLVMdev] Does nounwind have semantics? Kuperstein, Michael M wrote: > A patch is attached. + const CallInst* CI = dyn_cast<CallInst>(Inst); + return CI->isSafeToSpeculativelyExecute(); "return cast<CallInst>(Inst)->isSafeToSpeculativelyExecute();"? Use cast<> instead of dyn_cast<>. See http://llvm.org/docs/ProgrammersManual.html#isa . Then I don't think it needs to be two lines. You can even remove the extra curly braces aroun...

I'm not sure I understand why it's blocked on that, by the way. Even if we can't apply the attribute ourselves, I don't see why we wouldn't expose that ability to frontends. I'm not entirely sure "halting" is the right attribute either, by the way. What I, personally, would like to see is a way to specify a function call is safe to speculatively execute. That

Hi all, In light of recent discussions regarding updating passes to respect convergent semantics, and whether or not it is sufficient for barriers, I would like to propose a change in convergent semantics that should resolve a lot of the identified problems regarding loop unrolling, loop unswitching, etc. Credit to John McCall for talking this over with me and seeding the core ideas. Today,