On 5/14/19 4:57 PM, Jakub Jelinek wrote:
> On Tue, May 14, 2019 at 01:08:27PM -0600, Jeff Law wrote:
>>> In https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00484.html I've posted a
>>> patch that would set it earlier (or it could be set during gimplification
>>> and propagated during inlining, would
Hi Jakub, all,
> On 14 May 2019, at 23:57, Jakub Jelinek wrote:
>
> On Tue, May 14, 2019 at 01:08:27PM -0600, Jeff Law wrote:
>>> In https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00484.html I've posted a
>>> patch that would set it earlier (or it could be set during gimplification
>>> and
On Tue, May 14, 2019 at 01:08:27PM -0600, Jeff Law wrote:
> > In https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00484.html I've posted a
> > patch that would set it earlier (or it could be set during gimplification
> > and propagated during inlining, would need to be in cfun->calls_eh_return
> >
On 5/13/19 4:51 PM, Jakub Jelinek wrote:
> On Mon, May 13, 2019 at 04:29:21PM -0600, Jeff Law wrote:
>>> That is a serious misunderstanding of what __builtin_eh_return does.
>>> For the most part, __builtin_eh_return works by forcing all call clobbered
>>> registers to stack, having that described
Hi,
On Tue, 14 May 2019, Jakub Jelinek wrote:
> In https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00484.html I've posted
> a patch that would set it earlier (or it could be set during
> gimplification and propagated during inlining, would need to be in
> cfun->calls_eh_return instead of
On Mon, May 13, 2019 at 04:29:21PM -0600, Jeff Law wrote:
> > That is a serious misunderstanding of what __builtin_eh_return does.
> > For the most part, __builtin_eh_return works by forcing all call clobbered
> > registers to stack, having that described in the unwind info and having the
> >
On 5/13/19 2:09 PM, Jakub Jelinek wrote:
> On Mon, May 13, 2019 at 07:57:30PM +, Wilco Dijkstra wrote:
>> Hi,
>>
>>> I think my worry would be all the targets that support tail calls, but
>>> which we can't easily test. ie, we put in the hack, but when do we
>>> know it can be removed?
>>
>>
Hi Jakub,
>> We could simpify __builtin_eh_return and implement it as a libgcc
>> function or automatically generated thunk. Basically all you need is
>> tailcall a 2-instruction helper which adjusts the stack and then jumps
>> to the given function pointer. This way you don't need the complex
On Mon, May 13, 2019 at 07:57:30PM +, Wilco Dijkstra wrote:
> Hi,
>
> > I think my worry would be all the targets that support tail calls, but
> > which we can't easily test. ie, we put in the hack, but when do we
> > know it can be removed?
>
> Well it would be easy to make a runnable
Hi,
> I think my worry would be all the targets that support tail calls, but
> which we can't easily test. ie, we put in the hack, but when do we
> know it can be removed?
Well it would be easy to make a runnable torture test. I'm not sure
how easy it would be to do it using a scan-assembler
> On 13 May 2019, at 20:10, Jakub Jelinek wrote:
>
> On Mon, May 13, 2019 at 12:52:54PM -0600, Jeff Law wrote:
>> On 5/10/19 9:17 AM, Jakub Jelinek wrote:
>>> On Fri, May 10, 2019 at 01:46:07PM +, Wilco Dijkstra wrote:
And looking at the generated code, emitting a tailcall for this
On Mon, May 13, 2019 at 12:52:54PM -0600, Jeff Law wrote:
> On 5/10/19 9:17 AM, Jakub Jelinek wrote:
> > On Fri, May 10, 2019 at 01:46:07PM +, Wilco Dijkstra wrote:
> >> And looking at the generated code, emitting a tailcall for this case is
> >> actually a
> >> de-optimization since the
On 5/10/19 9:17 AM, Jakub Jelinek wrote:
> On Fri, May 10, 2019 at 01:46:07PM +, Wilco Dijkstra wrote:
>> And looking at the generated code, emitting a tailcall for this case is
>> actually a
>> de-optimization since the large eh_return epilog must be repeated for every
>> tailcall.
>
> On
On Sat, May 11, 2019 at 09:38:22AM +0100, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > Previously, the mere existence of the addressable variables this_context
> > and cur_context prevented tail call on the early out
> > return _Unwind_RaiseException (exc);
> > but since r271013 the
Jakub Jelinek writes:
> Hi!
>
> My recent patch for tail call improvement apparently affects also the
> _Unwind_Resume_or_Rethrow function in libgcc:
>
> _Unwind_Reason_Code __attribute__((optimize ("no-omit-frame-pointer")))
> _Unwind_Resume_or_Rethrow (struct _Unwind_Exception *exc)
> {
>
On Fri, May 10, 2019 at 01:46:07PM +, Wilco Dijkstra wrote:
> And looking at the generated code, emitting a tailcall for this case is
> actually a
> de-optimization since the large eh_return epilog must be repeated for every
> tailcall.
On x86_64, the code is shorter with the tail call
Hi Jakub,
>> That's great to hear, but all the other targets still need to be fixed
>> somehow.
>
> Not all other targets, just some. I don't see what you find wrong on
> actually fixing them. The tail call in that spot is actually very
> desirable, but only if we can do a shrink wrapping for
On Fri, May 10, 2019 at 01:46:07PM +, Wilco Dijkstra wrote:
> > So given this and the fact there is no real gain from emitting tailcalls in
> > eh_return
> > functions, wouldn't it make more sense to always block tailcalls in the
> > mid-end?
>
> > No. E.g. x86 handles that just fine,
>
Hi Jakub,
> So given this and the fact there is no real gain from emitting tailcalls in
> eh_return
> functions, wouldn't it make more sense to always block tailcalls in the
> mid-end?
> No. E.g. x86 handles that just fine,
That's great to hear, but all the other targets still need to be
On Fri, May 10, 2019 at 11:38:50AM +, Wilco Dijkstra wrote:
> > __builtin_eh_return is a noreturn call, and we never tail call optimize
> > noreturn calls:
> > if (flags & ECF_NORETURN)
> > {
> > maybe_complain_about_tail_call (exp, "callee does not return");
> > return false;
>
Hi Jakub,
> __builtin_eh_return is a noreturn call, and we never tail call optimize
> noreturn calls:
> if (flags & ECF_NORETURN)
> {
> maybe_complain_about_tail_call (exp, "callee does not return");
> return false;
> }
> As both the __builtin_eh_return and other tail calls are
On Fri, May 10, 2019 at 10:25:58AM +, Wilco Dijkstra wrote:
> Hi Jakub,
>
> 27ec: 912143ffadd sp, sp, #0x850
> 27f0: 8b2463ffadd sp, sp, x4
> 27f4: 1400b 23c8 <_Unwind_RaiseException>
>
> > This does a lot of register
Hi Jakub,
27ec: 912143ffadd sp, sp, #0x850
27f0: 8b2463ffadd sp, sp, x4
27f4: 1400b 23c8 <_Unwind_RaiseException>
> This does a lot of register saving and restoring, which is not needed but is
> not wrong-code (guess
Hi!
My recent patch for tail call improvement apparently affects also the
_Unwind_Resume_or_Rethrow function in libgcc:
_Unwind_Reason_Code __attribute__((optimize ("no-omit-frame-pointer")))
_Unwind_Resume_or_Rethrow (struct _Unwind_Exception *exc)
{
struct _Unwind_Context this_context,
24 matches
Mail list logo
