> Ok, so I plan to push this sparc fix into mainline and the 4.7 branch after
> my testing is done.
>
> Eric, any objections?
For the record, none.
--
Eric Botcazou
From: Richard Guenther
Date: Thu, 3 May 2012 12:25:11 +0200
> On Thu, May 3, 2012 at 11:52 AM, David Miller wrote:
>> From: Richard Guenther
>> Date: Thu, 3 May 2012 11:48:03 +0200
>>
>>> calls.c is unsafe, too. Which is probably why making DSE stronger for
>>> calls using the usual alias pred
On Thu, May 3, 2012 at 11:52 AM, David Miller wrote:
> From: Richard Guenther
> Date: Thu, 3 May 2012 11:48:03 +0200
>
>> calls.c is unsafe, too. Which is probably why making DSE stronger for
>> calls using the usual alias predicates did not work.
>
> Well, when calls.c does something more sophi
From: Richard Guenther
Date: Thu, 3 May 2012 11:48:03 +0200
> calls.c is unsafe, too. Which is probably why making DSE stronger for
> calls using the usual alias predicates did not work.
Well, when calls.c does something more sophisticated we can do similarly
for cases like sparc's libcalls.
On Thu, May 3, 2012 at 11:38 AM, David Miller wrote:
> From: Richard Sandiford
> Date: Thu, 03 May 2012 10:17:44 +0100
>
>> Richard Guenther writes:
>>> On Thu, May 3, 2012 at 10:31 AM, Richard Sandiford
>>> wrote:
David Miller writes:
> From: Richard Sandiford
> Date: Wed, 02 Ma
From: Richard Sandiford
Date: Thu, 03 May 2012 10:17:44 +0100
> Richard Guenther writes:
>> On Thu, May 3, 2012 at 10:31 AM, Richard Sandiford
>> wrote:
>>> David Miller writes:
From: Richard Sandiford
Date: Wed, 02 May 2012 20:37:58 +0100
> I think the DSE assuption is fai
From: Richard Guenther
Date: Thu, 3 May 2012 10:42:30 +0200
> On Thu, May 3, 2012 at 10:31 AM, Richard Sandiford
> wrote:
>> David Miller writes:
>>> From: Richard Sandiford
>>> Date: Wed, 02 May 2012 20:37:58 +0100
>>>
I think the DSE assuption is fair though. If you reuse MEMs like
>>>
Richard Guenther writes:
> On Thu, May 3, 2012 at 10:31 AM, Richard Sandiford
> wrote:
>> David Miller writes:
>>> From: Richard Sandiford
>>> Date: Wed, 02 May 2012 20:37:58 +0100
>>>
I think the DSE assuption is fair though. If you reuse MEMs like
this, then they're no longer just
On Thu, May 3, 2012 at 10:31 AM, Richard Sandiford
wrote:
> David Miller writes:
>> From: Richard Sandiford
>> Date: Wed, 02 May 2012 20:37:58 +0100
>>
>>> I think the DSE assuption is fair though. If you reuse MEMs like
>>> this, then they're no longer just serving the purpose described by
>>>
David Miller writes:
> From: Richard Sandiford
> Date: Wed, 02 May 2012 20:37:58 +0100
>
>> I think the DSE assuption is fair though. If you reuse MEMs like
>> this, then they're no longer just serving the purpose described by
>> MEM_EXPR.
>
> The following seems to work, and matches what calls.
From: Richard Sandiford
Date: Wed, 02 May 2012 20:37:58 +0100
> I think the DSE assuption is fair though. If you reuse MEMs like
> this, then they're no longer just serving the purpose described by
> MEM_EXPR.
The following seems to work, and matches what calls.c does when it
passes a value by
From: Richard Sandiford
Date: Wed, 02 May 2012 20:37:58 +0100
> I think the DSE assuption is fair though. If you reuse MEMs like this,
> then they're no longer just serving the purpose described by MEM_EXPR.
I think what Sparc does is fair, so if you are going to suggest that
I re-pop these val
From: Richard Sandiford
Date: Wed, 02 May 2012 20:37:58 +0100
> I think the problem is in the way sparc.c:emit_soft_tfmode_libcall
> reuses existing MEMs when passing arguments on the stack:
>
> if (GET_CODE (this_arg) == MEM
> && ! force_stack_temp)
> this_arg = XE
David Miller writes:
> On targets such as sparc, where ARG_POINTER_REGNUM ==
> FRAME_POINTER_REGNUM, some of the invariants currently built into DSE
> simply do not hold.
>
> Unlike how DSE assumes, we will in fact see stores to frame pointer
> relative addresses for setting up outgoing arguments
this looks ok to me, but I am going to defer this to richard for final
acceptance. his contribution to this pass was his deep knowledge of
rtl so that we could get the scanning correct and this is clearly in
that domain. He may have some trick that does not throw all of the
baby out with th
On targets such as sparc, where ARG_POINTER_REGNUM ==
FRAME_POINTER_REGNUM, some of the invariants currently built into DSE
simply do not hold.
Unlike how DSE assumes, we will in fact see stores to frame pointer
relative addresses for setting up outgoing arguments to a CALL.
The result is that D
16 matches
Mail list logo
