> From: Alan Modra
> Date: Tue, 1 Nov 2011 16:33:40 +0100
> On Tue, Nov 01, 2011 at 12:57:22AM +1030, Alan Modra wrote:
> * function.c (bb_active_p): Delete.
> (dup_block_and_redirect, active_insn_between): New functions.
> (convert_jumps_to_returns, emit_return_for_exit)
On Wed, Nov 02, 2011 at 02:03:40AM +1030, Alan Modra wrote:
> Bootstrapped and regression tested powerpc-linux. OK to apply?
> (And I won't be posting any more versions of the patch until this is
> reviewed. Please excuse me for spamming the list.)
Looks reasonable to me, appart from
> *
On Tue, Nov 01, 2011 at 12:57:22AM +1030, Alan Modra wrote:
> Bits left to do
> - limit size of duplicated tails
Done here. Also fixes a hole in that I took no notice of
targetm.cannot_copy_insn_p when duplicating tails.
One interesting result is that the tail duplication actually reduces
the te
So I'm at the point where I'm reasonably happy with this work. This
patch doesn't do anything particularly clever regarding our
shrink-wrap implementation. We still only insert one copy of the
prologue, and one of the epilogue in thread_prologue_and_epilogue.
All it really does is replaces Bernd'
On Thu, Oct 27, 2011 at 12:24:46AM +1030, Alan Modra wrote:
> more code than duplicating epilogues. From what I've seen, the
> duplicate tails are generally very small. I guess I should dump out
> some info so we can get a better idea.
There were 545 occurrences of shrink-wrap in the gcc/ dir fo
On Wed, Oct 26, 2011 at 03:59:36PM +0200, Bernd Schmidt wrote:
> On 10/26/11 15:54, Alan Modra wrote:
> > I guess the tradeoff between the classic shrink-wrap epilogue scheme
> > and my duplicate tail idea is whether duplicating tail blocks adds
> > more code than duplicating epilogues. From what
On 10/26/11 15:54, Alan Modra wrote:
> On Wed, Oct 26, 2011 at 03:01:01PM +0200, Bernd Schmidt wrote:
>> On 10/26/11 14:27, Alan Modra wrote:
>>> Committed revision 180522. It turns out that shrink-wrapping isn't as
>>> effective as it used to be with the 20110915 based sources I was using
>>> ori
On Wed, Oct 26, 2011 at 03:01:01PM +0200, Bernd Schmidt wrote:
> On 10/26/11 14:27, Alan Modra wrote:
> > Committed revision 180522. It turns out that shrink-wrapping isn't as
> > effective as it used to be with the 20110915 based sources I was using
> > originally. povray Ray_In_Bound no longer
On 10/26/11 14:27, Alan Modra wrote:
> Committed revision 180522. It turns out that shrink-wrapping isn't as
> effective as it used to be with the 20110915 based sources I was using
> originally. povray Ray_In_Bound no longer gets the benefit of shrink
> wrap, likely due to some cfg optimization.
On Sun, Oct 16, 2011 at 02:51:01PM -0400, David Edelsohn wrote:
> The patch is okay, although I am not thrilled about the need to change
> the register allocation order.
Committed revision 180522. It turns out that shrink-wrapping isn't as
effective as it used to be with the 20110915 based source
On Wed, Sep 28, 2011 at 11:47 AM, Alan Modra wrote:
> * config/rs6000/rs6000.c (rs6000_make_savres_rtx): Delete unneeded
> declaration.
> (rs6000_emit_stack_reset): Only return insn emitted when it adjusts sp.
> (rs6000_make_savres_rtx): Rename to rs6000_emit_savres_rt
This supercedes http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01004.html
and http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01593.html, fixing
the two regressions introduced by those patches. The first patch is
unchanged except to leave all the out-of-line restore functions using
"return" rather than
On Tue, Sep 27, 2011 at 02:15:24AM +0200, Bernd Schmidt wrote:
> That looks perfectly reasonable, and even if it is ordered in the way
> shown above, dwarf2cfi still should be able to deal with it if the
> prologue and epilogue are annotated correctly.
Here I was thinking that it was someone else'
On 09/27/11 02:11, Alan Modra wrote:
> On Tue, Sep 27, 2011 at 12:39:36AM +0200, Bernd Schmidt wrote:
>> On 09/27/11 00:32, Alan Modra wrote:
>>> On Mon, Sep 26, 2011 at 11:22:54PM +0930, Alan Modra wrote:
Two regressions appeared due to a problem in the shrink-wrap code.
>>>
>>> These two.
>>
On Tue, Sep 27, 2011 at 12:39:36AM +0200, Bernd Schmidt wrote:
> On 09/27/11 00:32, Alan Modra wrote:
> > On Mon, Sep 26, 2011 at 11:22:54PM +0930, Alan Modra wrote:
> >> Two regressions appeared due to a problem in the shrink-wrap code.
> >
> > These two.
> > +FAIL: g++.dg/torture/pr46111.C -O1
On 09/27/11 00:32, Alan Modra wrote:
> On Mon, Sep 26, 2011 at 11:22:54PM +0930, Alan Modra wrote:
>> Two regressions appeared due to a problem in the shrink-wrap code.
>
> These two.
> +FAIL: g++.dg/torture/pr46111.C -O1 (internal compiler error)
> +FAIL: gcc.dg/autopar/pr46099.c (internal comp
On Mon, Sep 26, 2011 at 11:22:54PM +0930, Alan Modra wrote:
> Two regressions appeared due to a problem in the shrink-wrap code.
These two.
+FAIL: g++.dg/torture/pr46111.C -O1 (internal compiler error)
+FAIL: gcc.dg/autopar/pr46099.c (internal compiler error)
Both "internal compiler error: in m
This patch fixes an issue that limit opportunities for shrink-wrapping
on PowerPC. The rs6000 REG_ALLOC_ORDER chooses r0 as the very first
gpr to use in code, with r11 also having high priority. This means it
is quite likely that r0 or r11 is live on the edge chosen for
shrink-wrapping. That's u
18 matches
Mail list logo
