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

[Sanjoy Das via llvm-dev]

Hi Hal,

On Thu, Jan 5, 2017 at 11:10 AM, Hal Finkel via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> It is still only a function of its arguments, so it can be CSE'd.

That's a good example -- we can CSE it without worrying about the
memory state flowing in.

In fact, if we have:

*a = 10;
call @readnone_may_unwind()
*a = 20;
call @readnone_may_unwind()
*a = 30;

then we can first transform this to:

*a = 10;
call @readnone_may_unwind()
*a = 20;
call @readnone_may_unwind()  nounwind // only on this call (since we
returned normally)
*a = 30;

and then DSE:

*a = 10;
call @readnone_may_unwind()
// *a = 20;
call @readnone_may_unwind()  nounwind // only on this call
*a = 30;


> Also, if I have this:
>
>  *a = 10;
>  b = a_readnone_unwind_func();
>  *a = 10;
>
> I can still conclude that this last store is redundant and can be removed. I
> know that the readnone function does not touch it, and if it unwinds, than
> the later store is dead. If I know that &*a has not escaped to where an
> exception handler might access it, then I know that the first store than be
> removed.

That's not specific to readnone though, right?  Even if the function
was readonly-mayunwind, the optimization would be legal.

>
>  -Hal
>
>
>
> 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
>
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>