On Wed, Aug 24, 2011 at 9:46 AM, Bernd Schmidt wrote:
> On 08/03/11 17:38, Richard Sandiford wrote:
>> Bernd Schmidt writes:
>>> +@findex simple_return
>>> +@item (simple_return)
>>> +Like @code{(return)}, but truly represents only a function return, while
>>> +@code{(return)} may represent an in
On 26 August 2011 15:36, Bernd Schmidt wrote:
> On 08/26/11 16:32, Ramana Radhakrishnan wrote:
>> On 24 August 2011 18:23, Bernd Schmidt wrote:
>>> On 08/24/11 19:17, Richard Sandiford wrote:
>
> You mean the introduction of simple_return patterns for ARM? The patch
> is split up further (this on
On 08/26/11 16:32, Ramana Radhakrishnan wrote:
> On 24 August 2011 18:23, Bernd Schmidt wrote:
>> On 08/24/11 19:17, Richard Sandiford wrote:
>>> OK with that change from a MIPS and rtl and perspective.
>>
>> Thanks. What else is in there? Trivial x86 changes, and a slightly less
>> trivial but st
On 24 August 2011 18:23, Bernd Schmidt wrote:
> On 08/24/11 19:17, Richard Sandiford wrote:
>> OK with that change from a MIPS and rtl and perspective.
>
> Thanks. What else is in there? Trivial x86 changes, and a slightly less
> trivial but still tiny ARM bit, I suppose. Richard/Ramana?
Sorry ab
On 08/24/11 19:17, Richard Sandiford wrote:
> OK with that change from a MIPS and rtl and perspective.
Thanks. What else is in there? Trivial x86 changes, and a slightly less
trivial but still tiny ARM bit, I suppose. Richard/Ramana?
Bernd
Bernd Schmidt writes:
> On 08/03/11 17:38, Richard Sandiford wrote:
>> Bernd Schmidt writes:
>>> +@findex simple_return
>>> +@item (simple_return)
>>> +Like @code{(return)}, but truly represents only a function return, while
>>> +@code{(return)} may represent an insn that also performs other func
On 08/03/11 17:38, Richard Sandiford wrote:
> Bernd Schmidt writes:
>> +@findex simple_return
>> +@item (simple_return)
>> +Like @code{(return)}, but truly represents only a function return, while
>> +@code{(return)} may represent an insn that also performs other functions
>> +of the function epil
Bernd Schmidt writes:
> +@findex simple_return
> +@item (simple_return)
> +Like @code{(return)}, but truly represents only a function return, while
> +@code{(return)} may represent an insn that also performs other functions
> +of the function epilogue. Like @code{(return)}, this may also occur in
On 08/03/11 12:41, Alan Modra wrote:
> This patch makes rebuild_jump_labels set JUMP_LABEL appropriately
> for return jumps, and fixes sharing for RETURN. Since ANY_RETURN_P(X)
> is defined as ((X) == ret_rtx), RETURNs need to stay shared.
> Bootstrapped and regression tested powerpc-linux and pow
On Thu, Jul 28, 2011 at 12:35:46PM +0200, Bernd Schmidt wrote:
[snip]
> * rtl.h (ANY_RETURN_P): New macro.
[snip]
This patch makes rebuild_jump_labels set JUMP_LABEL appropriately
for return jumps, and fixes sharing for RETURN. Since ANY_RETURN_P(X)
is defined as ((X) == ret_rtx), RETURNs n
On 07/07/11 16:34, Richard Sandiford wrote:
> I didn't review much after this, because it was hard to sort the
> simple_return stuff out from the "JUMP_LABEL can be a return rtx" change.
So, here's a second preliminary patch. Now that we have returns in
JUMP_LABELs, we can introduce SIMPLE_RETURN
On 07/29/11 00:31, Richard Earnshaw wrote:
> This causes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49891
Fixed with this.
Bernd
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 176904)
+++ gcc/ChangeLog (working c
On 28/07/11 11:35, Bernd Schmidt wrote:
> On 07/21/11 11:52, Richard Sandiford wrote:
>> The name "active_insn_after" seems a bit too similar to "next_active_insn"
>> for the difference to be obvious. How about something like
>> "first_active_target_insn" instead?
>
> Changed.
>>> - for (; insn;
Bernd Schmidt writes:
>>> - for (; insn; insn = next)
>>> + for (; insn && !ANY_RETURN_P (insn); insn = next)
>>> {
>>>if (NONJUMP_INSN_P (insn) && GET_CODE (PATTERN (insn)) == SEQUENCE)
>>> insn = XVECEXP (PATTERN (insn), 0, 0);
>>
>> Since ANY_RETURN looks for patterns, while
On 07/21/11 11:52, Richard Sandiford wrote:
> The name "active_insn_after" seems a bit too similar to "next_active_insn"
> for the difference to be obvious. How about something like
> "first_active_target_insn" instead?
Changed.
>> - for (; insn; insn = next)
>> + for (; insn && !ANY_RETURN_P (
Bernd Schmidt writes:
> On 07/07/11 16:34, Richard Sandiford wrote:
>> Is JUMP_LABEL ever null after this change? (In fully-complete rtl
>> sequences, I mean.) It looked like some of the null checks in the
>> patch might not be necessary any more.
>
> It turns out that computed jumps can have a
On 07/07/11 16:34, Richard Sandiford wrote:
> Is JUMP_LABEL ever null after this change? (In fully-complete rtl
> sequences, I mean.) It looked like some of the null checks in the
> patch might not be necessary any more.
It turns out that computed jumps can have a NULL JUMP_LABEL, and so can
JUM
On 07/11/11 13:08, Richard Sandiford wrote:
> Bernd Schmidt writes:
>> On 07/07/11 22:08, Richard Sandiford wrote:
>>> Sure, I understand that returns does more than return on ARM.
>>> What I meant was: we'd normally want that other stuff to be
>>> expressed in rtl alongside the (return) rtx. E.g
Bernd Schmidt writes:
> On 07/07/11 22:08, Richard Sandiford wrote:
>> Sure, I understand that returns does more than return on ARM.
>> What I meant was: we'd normally want that other stuff to be
>> expressed in rtl alongside the (return) rtx. E.g. something like:
>>
>> (parallel
>> [(retu
On 07/07/11 22:08, Richard Sandiford wrote:
> Sure, I understand that returns does more than return on ARM.
> What I meant was: we'd normally want that other stuff to be
> expressed in rtl alongside the (return) rtx. E.g. something like:
>
> (parallel
> [(return)
> (set (reg r4) (mem (
On 07/07/11 21:08, Richard Sandiford wrote:
> Richard Earnshaw writes:
>> On 07/07/11 15:34, Richard Sandiford wrote:
>>> It seems a shame to have both (return) and (simple_return). You said
>>> that we need the distinction in order to cope with targets like ARM,
>>> whose (return) instruction ac
Richard Earnshaw writes:
> On 07/07/11 15:34, Richard Sandiford wrote:
>> It seems a shame to have both (return) and (simple_return). You said
>> that we need the distinction in order to cope with targets like ARM,
>> whose (return) instruction actually performs some of the epilogue too.
>> It fe
On 07/07/11 19:05, Paul Koning wrote:
> From a note by Richard Henderson (June 30, 2011) it sounds like
> rs6000 is the other platform that still generates asm prologues. But
> yes, I said I would do this. It sounds like doing it soon would help
> Bernd a lot. Let me try to accelerate it.
Maybe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/07/11 11:05, Paul Koning wrote:
>
> On Jul 7, 2011, at 1:00 PM, Jeff Law wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 07/07/11 10:58, Paul Koning wrote:
>>>
>>> On Jul 7, 2011, at 11:38 AM, Bernd Schmidt wrote:
>>>
On Jul 7, 2011, at 1:00 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/07/11 10:58, Paul Koning wrote:
>>
>> On Jul 7, 2011, at 11:38 AM, Bernd Schmidt wrote:
>>
>>> ...
>>>
It'd also be nice to get rid of all these big blocks of code that are
condit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/07/11 10:58, Paul Koning wrote:
>
> On Jul 7, 2011, at 11:38 AM, Bernd Schmidt wrote:
>
>> ...
>>
>>> It'd also be nice to get rid of all these big blocks of code that are
>>> conditional on preprocessor macros, but I realise you're just follow
On Jul 7, 2011, at 11:38 AM, Bernd Schmidt wrote:
> ...
>
>> It'd also be nice to get rid of all these big blocks of code that are
>> conditional on preprocessor macros, but I realise you're just following
>> existing practice in the surrounding code, so again it can be left to
>> a future clean
On 07/07/11 15:34, Richard Sandiford wrote:
> It seems a shame to have both (return) and (simple_return). You said
> that we need the distinction in order to cope with targets like ARM,
> whose (return) instruction actually performs some of the epilogue too.
> It feels like the load of the saved r
Whee! Thanks for reviewing (reviving?) this old thing.
I should be posting an up-to-date version of this, but for the moment it
has to wait until dwarf2out is sorted out, and I'm rather busy with
other stuff. I hope to squeeze this in in the not too distant future.
I'll try to answer some of the
Bernd Schmidt writes:
> This adds the actual optimization, and reworks the JUMP_LABEL handling
> for return blocks. See the introduction mail or the new comment ahead of
> thread_prologue_and_epilogue_insns for more notes.
It seems a shame to have both (return) and (simple_return). You said
that
30 matches
Mail list logo
