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

Sanjoy Das via llvm-commits llvm-commits at lists.llvm.org
Sat Dec 31 17:54:29 PST 2016


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".

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.

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.  I can revert the patch in the meantime if
that'll make you more comfortable.

-- Sanjoy


More information about the llvm-commits mailing list