[llvm-dev] Funclet restrictions and Verifier

Reid Kleckner via llvm-dev llvm-dev at lists.llvm.org
Fri May 12 09:02:54 PDT 2017


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>


More information about the llvm-dev mailing list