search for: safe_to_specul

...on. If we go by the langref, then optimizations that fold undef are also problematic (though most C/C++ programs resulting in such IR would have UB in practice). I think there are non-(non-deterministic) problematic cases too. The following won't happen today since `readnone` does not imply `safe_to_speculate`, but if we add a `safe_to_speculate` property some day: int foo(bool C) available_externally { if (C) ((int *) null)++; // UB ret 42; } void bar() { if (<some cond>) foo(true); } Now, normally you can just delete the `if (C)` branch in foo, and i...

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Philip Reames" > <listmail at philipreames.com>, "Duncan P. N. Exon Smith" > <dexonsmith at apple.com>, "Sanjoy Das" >

...-----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hal Finkel Sent: Thursday, July 16, 2015 08:38 To: Raoux, Thomas F Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] LICM for function calls I think we'd need some kind of 'safe_to_speculate' attribute on the function. Regarding the optimization, under what circumstances would you want to speculate a function? I can imagine doing this only if I knew the function would be lowered in the backend to some simple set of instructions. -Hal -------------------------------------------...

...an identifying the interprocedural optimizations which are unsafe, which is essentially what disabling function attribute deduction is doing. > > I think there are non-(non-deterministic) problematic cases too. The > following won't happen today since `readnone` does not imply > `safe_to_speculate`, but if we add a `safe_to_speculate` property some > day: > > int foo(bool C) available_externally { > if (C) > ((int *) null)++; // UB > ret 42; > } > > void bar() { > if (<some cond>) > foo(true); > } > >...

...lded to some concrete value (instead of just being propagated), then yes, I agree. We really should be propagating the undef, however, right? > > I think there are non-(non-deterministic) problematic cases too. The > following won't happen today since `readnone` does not imply > `safe_to_speculate`, but if we add a `safe_to_speculate` property > some > day: > > int foo(bool C) available_externally { > if (C) > ((int *) null)++; // UB > ret 42; > } > > void bar() { > if (<some cond>) > foo(true); > } &gt...

...bling other optimizations. Given that all of our C++ constructors, inline functions, etc. end up in comdat sections, this is really important. > > I think there are non-(non-deterministic) problematic cases too. The > following won't happen today since `readnone` does not imply > `safe_to_speculate`, but if we add a `safe_to_speculate` property > some > day: > > int foo(bool C) available_externally { > if (C) > ((int *) null)++; // UB > ret 42; > } > > void bar() { > if (<some cond>) > foo(true); > } > > Now, normally you can just delet...

Hi, Right now in LICM (and many other transformations) we always assume it is never safe to speculatively execute a function call. The following function always return false for all function calls except for few intrinsics: bool llvm::isSafeToSpeculativelyExecute(const Value *V, const DataLayout *TD) { ... case Instruction::Call: { if (const