llvm dev - Mar 2014 - [LLVMdev] Is LowerInvoke's "-enable-correct-eh-support" option unused?

On 6 March 2014 18:09, Mark Seaborn <mseaborn at chromium.org> wrote:
> LowerAtomic "lowers atomic intrinsics to non-atomic form for use in a
> known non-preemptible environment".  LowerInvoke strips out exception
> handling by converting invokes to calls, so that landingpads, resumes, etc.
> become dead and can be removed by a later pass.
>
> (As an aside, LowerInvoke has an option for using SJLJ exception handling,
> but that option appears to be unused and replaced
> by lib/CodeGen/SjLjEHPrepare.cpp.)
>
On that topic, should LowerInvoke's "-enable-correct-eh-support"
option be
removed, since it appears to be unused?  If so, I can prepare a patch.

This option lowers exception handling to setjmp/longjmp, but it uses a
variable called "llvm.sjljeh.jblist" for the list of saved setjmp
frames.
 I've not found any code that looks at that list to implement throwing an
exception.  It looks like this was replaced by SjLjEHPrepare a long time
ago.

Cheers,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140307/d4f545dd/attachment.html>

IIRC, the LowerInvoke pass was for the C backend and is at least mostly
vestigial now. The SjLj style EH it did was very different from what the
SjLjEHPrepare pass implements.
-Jim
On Mar 7, 2014, at 5:12 PM, Mark Seaborn <mseaborn at chromium.org> wrote:
> On 6 March 2014 18:09, Mark Seaborn <mseaborn at chromium.org> wrote:
> LowerAtomic "lowers atomic intrinsics to non-atomic form for use in a
known non-preemptible environment".  LowerInvoke strips out exception
handling by converting invokes to calls, so that landingpads, resumes, etc.
become dead and can be removed by a later pass.
> 
> (As an aside, LowerInvoke has an option for using SJLJ exception handling,
but that option appears to be unused and replaced by
lib/CodeGen/SjLjEHPrepare.cpp.)
> 
> On that topic, should LowerInvoke's
"-enable-correct-eh-support" option be removed, since it appears to be
unused?  If so, I can prepare a patch.
> 
> This option lowers exception handling to setjmp/longjmp, but it uses a
variable called "llvm.sjljeh.jblist" for the list of saved setjmp
frames.  I've not found any code that looks at that list to implement
throwing an exception.  It looks like this was replaced by SjLjEHPrepare a long
time ago.
> 
> Cheers,
> Mark
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140310/ae3948d6/attachment.html>

Right. So it can be safely removed.

On Mon, Mar 10, 2014 at 11:06 PM, Jim Grosbach <grosbach at apple.com>
wrote:
> IIRC, the LowerInvoke pass was for the C backend and is at least mostly
> vestigial now. The SjLj style EH it did was very different from what the
> SjLjEHPrepare pass implements.
> -Jim
> On Mar 7, 2014, at 5:12 PM, Mark Seaborn <mseaborn at chromium.org>
wrote:
>
> On 6 March 2014 18:09, Mark Seaborn <mseaborn at chromium.org> wrote:
>>
>> LowerAtomic "lowers atomic intrinsics to non-atomic form for use
in a
>> known non-preemptible environment".  LowerInvoke strips out
exception
>> handling by converting invokes to calls, so that landingpads, resumes,
etc.
>> become dead and can be removed by a later pass.
>>
>> (As an aside, LowerInvoke has an option for using SJLJ exception
handling,
>> but that option appears to be unused and replaced by
>> lib/CodeGen/SjLjEHPrepare.cpp.)
>
>
> On that topic, should LowerInvoke's
"-enable-correct-eh-support" option be
> removed, since it appears to be unused?  If so, I can prepare a patch.
>
> This option lowers exception handling to setjmp/longjmp, but it uses a
> variable called "llvm.sjljeh.jblist" for the list of saved setjmp
frames.
> I've not found any code that looks at that list to implement throwing
an
> exception.  It looks like this was replaced by SjLjEHPrepare a long time
> ago.
>
> Cheers,
> Mark
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University