> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Paolo Bonzini
> Sent: 07 May 2009 14:53
> To: m...@codesourcery.com
> Cc: gcc@gcc.gnu.org; Ramana Radhakrishnan; Richard Earnshaw
> Subject: cond-optab merge delay? [was
Paolo Bonzini wrote:
> I'll go for Tuesday unless I get a "go" from either Richard Earnshaw
> (ARM maintainer and global reviewer) or Ramana Radhakrishnan (who's
> taking care of bootstrapping the ARM-fixing patch).
That's fine.
Thank you for taking the ARM situation into account,
--
Mark Mitc
> The slush that I requested last week has been lifted. However, I have
> asked for relative calm until the cond-optab branch has been merged to
> mainline, which will hopefully occur on Friday, May 8th.
cond-optab branch was bootstrapped on arm-linux among other targets, so
the merge should not
> -Original Message-
> From: Michael Matz [mailto:m...@suse.de]
> Sent: 06 May 2009 18:00
> To: Richard Earnshaw
> Cc: Paolo Bonzini; Joern Rennecke; Ramana Radhakrishnan;
> m...@codesourcery.com; gcc@gcc.gnu.org
> Subject: Re: Setting ARM PIC register (Was: RE: GC
> I.e. like so. It fixes the testcase and to my untrained eye the output
> looks correct (at least there seems to be loads from something .PIC
> related :) ). But better testing would be appreciated.
A comment explaining who will call commit_edge_insertions like in the Alpha
case would be nice
Hi,
On Wed, 6 May 2009, Michael Matz wrote:
> > There's already emit_insn_at_entry in cfgrtl.c. Would that work?
>
> Unfortunately not. That one also wants to immediately commit the just
> inserted instructions, which doesn't work during the transition phase
> from GIMPLE to RTL. But just q
Hi,
On Wed, 6 May 2009, Richard Earnshaw wrote:
> > Or like alpha:
> >
> > insert_insn_on_edge (seq, single_succ_edge (ENTRY_BLOCK_PTR));
> >
> > That's not for the PIC load, but should work okay as expand from SSA
> > commits instructions on edges later. That actually seems even nicer
> >
On Wed, 2009-05-06 at 18:29 +0200, Michael Matz wrote:
> Hi,
>
> On Wed, 6 May 2009, Paolo Bonzini wrote:
>
> > Looks like something like this could be useful to avoid code
> > duplications in the backends:
> >
> > void
> > emit_insn_at_top (rtx insn)
> > {
> > rtx scan;
> >
> > gcc_assert
Hi,
On Wed, 6 May 2009, Paolo Bonzini wrote:
> Looks like something like this could be useful to avoid code
> duplications in the backends:
>
> void
> emit_insn_at_top (rtx insn)
> {
> rtx scan;
>
> gcc_assert (current_ir_type () != IR_RTL_CFGLAYOUT);
> push_topmost_sequence ();
> scan
Hi,
On Wed, 6 May 2009, Mark Mitchell wrote:
> >> How about emitting a set at each place the PIC register is needed,
> >> and making sure that gcse will will common these sets where
> >> appropriate?
>
> > I'd rather not. -O0 code is bad enough already; and this just makes
> > more work for
Michael Matz wrote:
> Hi,
>
> On Wed, 6 May 2009, Joern Rennecke wrote:
>
>> Richard Earnshaw:
>>> That won't work because the PIC register on ARM is a pseudo, so
>>> generating it during prologue generation is too late. It needs to exist
>>> before data flow analysis starts on the RTL.
>> How a
Hi,
On Wed, 6 May 2009, Joern Rennecke wrote:
> Richard Earnshaw:
> >That won't work because the PIC register on ARM is a pseudo, so
> >generating it during prologue generation is too late. It needs to exist
> >before data flow analysis starts on the RTL.
>
> How about emitting a set at each pl
Richard Earnshaw wrote:
The easiest solution would be to just make a note that you need the
PIC register and then, when expanding the prologue emit the
necessary instructions. IMO that makes sense as PIC register setup
usually is something the prologue does, like all the
On Wed, 2009-05-06 at 12:03 -0400, Joern Rennecke wrote:
> Michael Matz wrote:
> >> The easiest solution would be to just make a note that you need the
> >> PIC register and then, when expanding the prologue emit the
> >> necessary instructions. IMO that makes sense as PIC register setup
> >
Michael Matz wrote:
The easiest solution would be to just make a note that you need the
PIC register and then, when expanding the prologue emit the
necessary instructions. IMO that makes sense as PIC register setup
usually is something the prologue does, like all the other register
setups
On Wed, 2009-05-06 at 17:55 +0200, Michael Matz wrote:
> Hi,
>
> On Wed, 6 May 2009, Richard Earnshaw wrote:
>
> > > The easiest solution would be to just make a note that you need the
> > > PIC register and then, when expanding the prologue emit the necessary
> > > instructions. IMO that make
Hi,
On Wed, 6 May 2009, Richard Earnshaw wrote:
> > The easiest solution would be to just make a note that you need the
> > PIC register and then, when expanding the prologue emit the necessary
> > instructions. IMO that makes sense as PIC register setup usually is
> > something the prologue
On Wed, 2009-05-06 at 17:49 +0200, Richard Guenther wrote:
> On Wed, May 6, 2009 at 5:46 PM, Richard Earnshaw wrote:
> > That won't work because the PIC register on ARM is a pseudo, so
> > generating it during prologue generation is too late. It needs to exist
> > before data flow analysis start
On Wed, May 6, 2009 at 5:46 PM, Richard Earnshaw wrote:
> On Wed, 2009-05-06 at 17:44 +0200, Michael Matz wrote:
>> Hi,
>>
>> On Wed, 6 May 2009, Ramana Radhakrishnan wrote:
>>
>> > >>> The slush that I requested last week has been lifted. However, I
>> > >>> have asked for relative calm until th
On Wed, 2009-05-06 at 17:44 +0200, Michael Matz wrote:
> Hi,
>
> On Wed, 6 May 2009, Ramana Radhakrishnan wrote:
>
> > >>> The slush that I requested last week has been lifted. However, I
> > >>> have asked for relative calm until the cond-optab branch has been
> > >>> merged to mainline, whic
Hi,
On Wed, 6 May 2009, Ramana Radhakrishnan wrote:
> >>> The slush that I requested last week has been lifted. However, I
> >>> have asked for relative calm until the cond-optab branch has been
> >>> merged to mainline, which will hopefully occur on Friday, May 8th.
> >>
> >> As of this morni
been seeing with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929#c12.
Ramana
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Mark Mitchell
> Sent: 06 May 2009 16:10
> To: Richard Earnshaw
> Cc: gcc@gcc.gnu.org
> Subject:
Richard Earnshaw wrote:
>> The slush that I requested last week has been lifted. However, I have
>> asked for relative calm until the cond-optab branch has been merged to
>> mainline, which will hopefully occur on Friday, May 8th.
>
> As of this morning (UK), native bootstrap on ARM is still bro
On Tue, 2009-05-05 at 09:25 -0700, Mark Mitchell wrote:
> Clearly, we have had a significant jump in P1 issues due to the major
> changes made to the compiler middle-end. Let's drive that number
> down -- otherwise it will be hard for other people to get their
> improvements contributed.
> The sl
Status
==
The trunk is in Stage 1. As previously stated, we expect that Stage 1
will last through at least July.
Clearly, we have had a significant jump in P1 issues due to the major
changes made to the compiler middle-end. Let's drive that number
down -- otherwise it will be hard for othe
25 matches
Mail list logo
