GCC 4.5.0 Status Report (2009-05-05)

GCC 4.5.0 Status Report (2009-05-05)

[Mark Mitchell]

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 other people to get their
improvements contributed.

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.

Quality Data
============

Priority	  #	Change from Last Report
--------	---	-----------------------
P1		 16     + 16
P2		 83 	+ 10
P3		  1	- 14   
--------	---	-----------------------
Total		100	+ 12

Previous Report
===============

http://gcc.gnu.org/ml/gcc/2009-04/msg00565.html

The next report for 4.4.0 will be sent by Richard.

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: GCC 4.5.0 Status Report (2009-05-05)

[Richard Earnshaw]

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 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 broken.

R.

Re: GCC 4.5.0 Status Report (2009-05-05)

[Mark Mitchell]

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 broken.

Is this PR 39978?

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

RE: GCC 4.5.0 Status Report (2009-05-05)

[Ramana Radhakrishnan]

On Wed, May 6, 2009 at 4:10 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> 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 broken.
>
> Is this PR 39978?

I see what's been reported at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40031#c2 on gcc55 which appears
to be the same crash as what Julian's been seeing with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929#c12.


Ramana

> -----Original Message-----
> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of
> Mark Mitchell
> Sent: 06 May 2009 16:10
> To: Richard Earnshaw
> Cc: gcc@gcc.gnu.org
> Subject: Re: GCC 4.5.0 Status Report (2009-05-05)
> 
> 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 broken.
> 
> Is this PR 39978?
> 
> Thanks,
> 
> --
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713

RE: GCC 4.5.0 Status Report (2009-05-05)

[Michael Matz]

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 morning (UK), native bootstrap on ARM is still broken.
> >
> > Is this PR 39978?
> 
> I see what's been reported at
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40031#c2 on gcc55 which appears
> to be the same crash as what Julian's been seeing with
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929#c12.

As written by Andrew Pinski already, you'll need a different method of 
emitting the load of the PIC register.  The ARM backend tries to emit that 
load as soon as it sees the PIC register being used (which is a slightly 
odd method as it magically emits instructions at a place unrelated to the 
instruction that currently are supposed to be emitted).

With expand from SSA this happens earlier than before, in fact so early 
that you don't have any basic block in RTL yet.  All are still in gimple 
form.  That's why the emission of RTL insns after the function entry is 
not going to work.  That's only possible if everything is transformed 
already.

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 necessary.

So, in require_pic_register, do everything as before, except move the 
block emitting the load:
              start_sequence ();
              arm_load_pic_register (0UL);
              seq = get_insns ();
              end_sequence ();

into the prologue generator.


Ciao,
Michael.

RE: GCC 4.5.0 Status Report (2009-05-05)

[Richard Earnshaw]

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, which will hopefully occur on Friday, May 8th.
> > >>
> > >> As of this morning (UK), native bootstrap on ARM is still broken.
> > >
> > > Is this PR 39978?
> > 
> > I see what's been reported at
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40031#c2 on gcc55 which appears
> > to be the same crash as what Julian's been seeing with
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929#c12.
> 
> As written by Andrew Pinski already, you'll need a different method of 
> emitting the load of the PIC register.  The ARM backend tries to emit that 
> load as soon as it sees the PIC register being used (which is a slightly 
> odd method as it magically emits instructions at a place unrelated to the 
> instruction that currently are supposed to be emitted).
> 
> With expand from SSA this happens earlier than before, in fact so early 
> that you don't have any basic block in RTL yet.  All are still in gimple 
> form.  That's why the emission of RTL insns after the function entry is 
> not going to work.  That's only possible if everything is transformed 
> already.
> 
> 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 necessary.
> 

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.

R.
-- 
Richard Earnshaw             Email: Richard.Earnshaw@arm.com
Engineering Manager          Phone: +44 1223 400569 (Direct + VoiceMail)
OpenSource Tools             Switchboard: +44 1223 400400
ARM Ltd                      Fax: +44 1223 400410
110 Fulbourn Rd              Web: http://www.arm.com/
Cambridge, UK. CB1 9NJ

Re: GCC 4.5.0 Status Report (2009-05-05)

[Richard Guenther]

On Wed, May 6, 2009 at 5:46 PM, Richard Earnshaw <rearnsha@arm.com> 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 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 broken.
>> > >
>> > > Is this PR 39978?
>> >
>> > I see what's been reported at
>> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40031#c2 on gcc55 which appears
>> > to be the same crash as what Julian's been seeing with
>> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929#c12.
>>
>> As written by Andrew Pinski already, you'll need a different method of
>> emitting the load of the PIC register.  The ARM backend tries to emit that
>> load as soon as it sees the PIC register being used (which is a slightly
>> odd method as it magically emits instructions at a place unrelated to the
>> instruction that currently are supposed to be emitted).
>>
>> With expand from SSA this happens earlier than before, in fact so early
>> that you don't have any basic block in RTL yet.  All are still in gimple
>> form.  That's why the emission of RTL insns after the function entry is
>> not going to work.  That's only possible if everything is transformed
>> already.
>>
>> 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 necessary.
>>
>
> 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.

So you can generate it unconditionally and let DCE remove it if it turns
out not necessary?

Richard.

Re: GCC 4.5.0 Status Report (2009-05-05)

[Richard Earnshaw]

On Wed, 2009-05-06 at 17:49 +0200, Richard Guenther wrote:
> On Wed, May 6, 2009 at 5:46 PM, Richard Earnshaw <rearnsha@arm.com> 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 starts on the RTL.
> 
> So you can generate it unconditionally and let DCE remove it if it turns
> out not necessary?

Sorry, is that a question about the ARM back end as it worked before all
these changes went in, or how I might solve the problem now.  If the
latter, then generate what, where and when?

R.

RE: GCC 4.5.0 Status Report (2009-05-05)

[Michael Matz]

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 does, like all the other register setups 
> > necessary.
> 
> 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.

That's fine.  You can generate the pseudo, just not emit the code to load 
it until prologue generation starts.  Dataflow analysis starts only after 
everything is expanded to RTL anyway.  I'll try to cobble up a patch to 
show what I mean, but obviously I'm not very fluent with the ARM backend.


Ciao,
Michael.

RE: GCC 4.5.0 Status Report (2009-05-05)

[Richard Earnshaw]

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 makes sense as PIC register setup usually is 
> > > something the prologue does, like all the other register setups 
> > > necessary.
> > 
> > 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.
> 
> That's fine.  You can generate the pseudo, just not emit the code to load 
> it until prologue generation starts.  Dataflow analysis starts only after 
> everything is expanded to RTL anyway.  I'll try to cobble up a patch to 
> show what I mean, but obviously I'm not very fluent with the ARM backend.

Sorry, I'm confused.  Prologue generation happens after register
allocation (it can't be otherwise since we don't know which registers
have to be saved).  The PIC register has to appear as being live at the
start of the function so that the uses of it don't appear to be magic.

R.

cond-optab merge delay? [was Re: GCC 4.5.0 Status Report (2009-05-05)]

[Paolo Bonzini]

> 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 introduce any new problem.  Still, because the ARM
crash has not been solved yet, I will perform the merge either on Friday
8th *afternoon* or on Tuesday 12th *morning* (always European time).

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).

Paolo

Re: cond-optab merge delay? [was Re: GCC 4.5.0 Status Report (2009-05-05)]

[Mark Mitchell]

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 Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

RE: cond-optab merge delay? [was Re: GCC 4.5.0 Status Report (2009-05-05)]

[Ramana Radhakrishnan]

> -----Original Message-----
> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of
> Paolo Bonzini
> Sent: 07 May 2009 14:53
> To: mark@codesourcery.com
> Cc: gcc@gcc.gnu.org; Ramana Radhakrishnan; Richard Earnshaw
> Subject: cond-optab merge delay? [was Re: GCC 4.5.0 Status Report
> (2009-05-05)]
> 
> 
> > 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 introduce any new problem.  Still, because the ARM
> crash has not been solved yet, I will perform the merge either on
> Friday
> 8th *afternoon* or on Tuesday 12th *morning* (always European time).
> 
> 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).

The patch thanks to Michael got arm-linux-gnueabi bootstrapping again. The
tests are still running and I don't notice anything untoward with atleast
the ARM tests. It's now cycling on to the thumb tests.

cheers
Ramana
> 
> Paolo