[PATCH] D28147: [LICM] Allow promotion of some stores that are not guaranteed to execute

[Daniel Berlin via llvm-commits]

On Sat, Dec 31, 2016 at 5:54 PM, Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> Hi Daniel,
>
> On Sat, Dec 31, 2016 at 4:44 PM, Daniel Berlin <dberlin at dberlin.org>
> wrote:
> [snip]
> > 2. I have no problem with us with deciding what we mean in either
> direction.
> > I just believe it's worth having a real mailing list discussion about it
> not
> > buried in this particular thread, before making such a patch.
>
> (For brevity, when I say readnone, I mean readnone / readonly)
>
> I think LLVM today already has a strong bent towards "readnone
> functions *can* unwind".
>

How does one unwind without writing memory?


> a. We don't CSE the call to @f() in
>
>   declare void @f() readnone
>
>   define void @g() {
>     call void @f()
>     ret void
>   }
>
> unless @f is also marked nounwind.
>
One can argue these are missed opts :)


>
> b. We infer readnone for a function that has resume in it (example
>    earlier in the thread).
>
>
> And, finally, we don't actually get any new expressive power out of
> the assumption.  If the frontend knows that readnone functions are
> nounwind by the language spec then it can mark declarations that it
> was going to mark as readnone as "readnone nounwind" (for instance,
> clang marks pure and const functions as nounwind also).  And I can't
> think of a case where function attrs would be able to deduce readnone
> and not nounwind for a legitimately nounwind function.
>
> I'll start a thread on llvm-dev (not today, but tomorrow or Monday) to
> set the wheels in motion.


Sounds good to me.

>   I can revert the patch in the meantime if
> that'll make you more comfortable.
>
> Nope. I just want us to end up in a consistent end state.
I don't see how you have a readnone function unwind, but i also have no
real dog in this fight.



> -- Sanjoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161231/8eb818c0/attachment.html>