llvm dev - May 2017 - Funclet restrictions and Verifier

Hi, Folks!
There are restrictions on the IR that is allowed inside a funclet which are
not enforced by the verifier.
Among them:

   - [1]* No variables live into or out of the funclet can be allocated in
   registers.*
   - [2]* If any funclet EH pads have been “entered” but not “exited” it is
   undefined behavior to execute a call or invoke which:*
      - *does not have a "funclet" bundle and is not a call to a
nounwind
      intrinsic, or*
      - *has a "funclet" bundle whose operand is not the
      most-recently-entered not-yet-exited funclet EH pad.*

Is there any reason for the Verifier not to enforce these constraints? I
started to add these checks to the Verifier.

Cheers,
Juan

[1] http://llvm.org/docs/ExceptionHandling.html#id32
[2] http://llvm.org/docs/LangRef.html#funclet-operand-bundles
-- 

Juan Manuel Martinez Caamaño
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170512/d07bbbec/attachment.html>

On Fri, May 12, 2017 at 8:14 AM, Juan Manuel Martinez Caamaño via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi, Folks!
> There are restrictions on the IR that is allowed inside a funclet which
> are not enforced by the verifier.
> Among them:
>
>    - [1]* No variables live into or out of the funclet can be allocated
>    in registers.*
>
> This is achieved transparently in the backend with a full register clobber
in funclet prologue and epilogue BBs.
>
>    - [2]* If any funclet EH pads have been “entered” but not “exited” it
>    is undefined behavior to execute a call or invoke which:*
>       - *does not have a "funclet" bundle and is not a call to a
nounwind
>       intrinsic, or*
>       - *has a "funclet" bundle whose operand is not the
>       most-recently-entered not-yet-exited funclet EH pad.*
>
> It's UB, so we don't need to enforce it in the verifier. We
transform
these calls to unreachable in WinEHPrepare.

I don't think we can enforce it. I can't remember the example off the
top
of my head, but valid IR transformations can introduce edges from funclets
to calls with the wrong funclet bundle. By not enforcing this rule in the
Verifier, we allow those transformations to remain blissfully unaware of
funclet insanity.

> Is there any reason for the Verifier not to enforce these constraints? I
> started to add these checks to the Verifier.
>
> Cheers,
> Juan
>
> [1] http://llvm.org/docs/ExceptionHandling.html#id32
> [2] http://llvm.org/docs/LangRef.html#funclet-operand-bundles
> --
>
> Juan Manuel Martinez Caamaño
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170512/ea931889/attachment.html>