[llvm-dev] RFC: Allow readnone and readonly functions to throw exceptions

[Sanjoy Das via llvm-dev]

Hi Mehdi,

On Thu, Jan 5, 2017 at 10:45 AM, Mehdi Amini via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
[snip]
> I don't understand why that's desirable, and I think it would severely limit
> our ability to infer these attributes for functions that unwind. You'd need
> to prove things -- likely unknowable things -- about the exception handlers
> in place around every call site of a function in order to mark it readonly,
> readnone, etc. We'd have the same problem with the attribute parameters. I'm
> fairly certain we do need and want to separate these concerns. This way we
> can apply callsite specific reasoning to the potential effects of exception
> handlers separate from what the function itself might do.
>
>
> What useful things would you be able to deduce from an “unwind readnone”
> function under these conditions?

In theory you could do this transform:

void f(int*a) {
  *a = 20;
  call @mayunwind_readnone();
  *a = 30;
}

=>

void f(int*a) {
  // *a = 20;
  invoke @mayunwind_readnone() to %normal unwind %unwind

normal:
  *a = 30;
  ret void

unwind:
  %exc = landingpad
  *a = 20;
  resume %exc
}

(That is, PRE the store around the implicit edge by making it explicit.)

Generally though I don't see us doing this except under exceptional
(no pun intended!) circumstances.

-- Sanjoy



>
>
> I don't think we'll do DSE in your example because the store isn't dead,
> it's visible along the invoke's unwind edge, and we don't need to change the
> semantics of readnone to see that.
>
>
> I’ve been wondering the same thing on Sanjoy’s example.
>
> —
> Mehdi
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>