llvm dev - Jan 2018 - Exception handling support for a target

On 22 Jan 2018, at 14:15, Krzysztof Parzyszek via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On 1/19/2018 7:21 PM, 陳韋任 wrote:
>> I see X86, Mips, XCore and Hexagon define their own EH_RETURN and lower
to it, but others don't. May I know why it's so on Hexagon?
> 
> Our exception handling runtime uses __builtin_eh_return.
Does this mean that you know what it does?  If so, please could you document it
somewhere?

David

On 1/22/2018 8:40 AM, David Chisnall wrote:
> On 22 Jan 2018, at 14:15, Krzysztof Parzyszek via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>> On 1/19/2018 7:21 PM, 陳韋任 wrote:
>>> I see X86, Mips, XCore and Hexagon define their own EH_RETURN and
lower to it, but others don't. May I know why it's so on Hexagon?
>>
>> Our exception handling runtime uses __builtin_eh_return.
> 
> Does this mean that you know what it does?  If so, please could you
document it somewhere?
I don't actually, but I can find out.

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

2018-01-23 21:49 GMT+08:00 Krzysztof Parzyszek <kparzysz at
codeaurora.org>:
> On 1/22/2018 8:40 AM, David Chisnall wrote:
>
>> On 22 Jan 2018, at 14:15, Krzysztof Parzyszek via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>>
>>> On 1/19/2018 7:21 PM, 陳韋任 wrote:
>>>
>>>> I see X86, Mips, XCore and Hexagon define their own EH_RETURN
and lower
>>>> to it, but others don't. May I know why it's so on
Hexagon?
>>>>
>>>
>>> Our exception handling runtime uses __builtin_eh_return.
>>>
>>
>> Does this mean that you know what it does?  If so, please could you
>> document it somewhere?
>>
>
> I don't actually, but I can find out.

​Thanks! Welcome leave comment on https://reviews.llvm.org/D42178 . ;-)​

-- 
Wei-Ren Chen (陳韋任)
Homepage: https://people.cs.nctu.edu.tw/~chenwj
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180123/ca0dfeb9/attachment.html>

The high level of what happens is that __builtin_eh_return forces a spill of all
the non-volatile registers.  The unwinder then has a starting point for
populating and adjusting those non-volatile registers.

This approach usually requires that the function calling __builtin_eh_return be
built without optimizations, because the optimizer will then remove the spills.

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of ??? via
llvm-dev
Sent: Tuesday, January 23, 2018 8:05 AM
To: Krzysztof Parzyszek <kparzysz at codeaurora.org<mailto:kparzysz at
codeaurora.org>>
Cc: LLVM Developers Mailing List <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
Subject: Re: [llvm-dev] Exception handling support for a target



2018-01-23 21:49 GMT+08:00 Krzysztof Parzyszek <kparzysz at
codeaurora.org<mailto:kparzysz at codeaurora.org>>:
On 1/22/2018 8:40 AM, David Chisnall wrote:
On 22 Jan 2018, at 14:15, Krzysztof Parzyszek via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

On 1/19/2018 7:21 PM, 陳韋任 wrote:
I see X86, Mips, XCore and Hexagon define their own EH_RETURN and lower to it,
but others don't. May I know why it's so on Hexagon?

Our exception handling runtime uses __builtin_eh_return.

Does this mean that you know what it does?  If so, please could you document it
somewhere?

I don't actually, but I can find out.

​Thanks! Welcome leave comment on
https://reviews.llvm.org/D42178<https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D42178&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=1sH2On5zK0AZLrvY22_45N0ZUBp-mtahhyRYV0uR_IQ&s=zhjxLR2PgLx2Fs08E-JWyDP-D814BdLZgZWk31-grag&e=>
. ;-)​

--
Wei-Ren Chen (陳韋任)
Homepage:
https://people.cs.nctu.edu.tw/~chenwj<https://urldefense.proofpoint.com/v2/url?u=https-3A__people.cs.nctu.edu.tw_-7Echenwj&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=1sH2On5zK0AZLrvY22_45N0ZUBp-mtahhyRYV0uR_IQ&s=AnYFbnifu7HPV168vOg9FaNPj84YKgQS6Jw1kJunfEg&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180123/76c0f71c/attachment.html>

2018-01-24 0:23 GMT+08:00 Ben Craig <ben.craig at ni.com>:
> The high level of what happens is that __builtin_eh_return forces a spill
> of all the non-volatile registers.  The unwinder then has a starting point
> for populating and adjusting those non-volatile registers.
>
>
>
> This approach usually requires that the function calling
> __builtin_eh_return be built without optimizations, because the optimizer
> will then remove the spills.
>
​Ben, thanks for your input. However, I don't quite understand what you
said.

​The prototype of ​__builtin_eh_return (offset, handler) [1], I can't see
why it forces spilling all non-volatile registers (I assume non-volatile
=callee-saved).

​Take libgcc as an example, __built_eh_return is called in
uw_install_context [1], which is called in the end of
_Unwind_RaiseException [2]. Do you mean we should compile libgcc without
optimization?

​[1] https://github.com/gcc-mirror/gcc/blob/master/libgcc/unwind-dw2.c​
[2] https://github.com/gcc-mirror/gcc/blob/master/libgcc/unwind.inc​

-- 
Wei-Ren Chen (陳韋任)
Homepage: https://people.cs.nctu.edu.tw/~chenwj
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180124/8e05e17b/attachment.html>