search for: mayreturn

Displaying 4 results from an estimated 4 matches for "mayreturn".

Did you mean: canreturn
2013 Feb 21
0
[LLVMdev] [llvm] r175553 - Fix a bug in mayHaveSideEffects. Functions that do not return are now considered as instructions with side effects.
Hi Nadav, > I almost missed your email because you replied only to the list. I understand your argument. I think that my fix addresses a part of it. It says that instructions that do not return should not be removed. > The current implementation of mayReturn is to check the 'noreturn' function attribute. Are you suggesting to add a new attribute that is called 'mustreturn' ? It is as equally difficult to know if a function will halt. a function would only be 'mustreturn' [*] if you can prove that it must return in finite time....
2013 Mar 09
1
[LLVMdev] Does a recursive call have side effects?
...e functions as dead code. I assume this falls under the same language rules that allow removal of infinite loops. But I need to be certain. Can someone confirm? Standard citations welcome. Otherwise this is wrong: bool mayHaveSideEffects() const { return mayWriteToMemory() || mayThrow() || !mayReturn(); } Note: For non-C support, it would be nice to have another attribute, maynotreturn (in C everything is mustreturn by default). In theory, if we had that, the C frontend could use it for potentially recursive calls, forcing the optimizer to either prove it's not recursive or consider it t...
2016 Mar 21
3
New intrinsic property IntrOnlyWrite
On 19.03.2016 16:25, Mehdi Amini wrote: > Hi, > > Can you elaborate what is the impact at the IR level? > If the point is just about how you lower for you target, why are you needing an IR level attribute? You backend if free to specialize the lowering for any intrinsic regardless the IR level attributes. As I explained in my reply to Philip, what I really need is a way to get
2016 Mar 22
1
New intrinsic property IntrOnlyWrite
...cts", I believe this is incorrect considering the above description. -- Mehdi > > At the IR level, the definition of "mayHaveSideEffects" is more coherent with what I expect: > > bool mayHaveSideEffects() const { > return mayWriteToMemory() || mayThrow() || !mayReturn(); > } > >> Indeed, write-only without an ArgMemOnly property may well be useless at the IR level. If you think that there is a better way to explain the situation to TableGen, please let me know. > > I don't really understand why an MI which is "mayLoad" would ha...