GCC 4.3.0 Status Report (2007-09-04)

GCC 4.3.0 Status Report (2007-09-04)

[Mark Mitchell]

Summary
=======

We are closing in on Stage 3, previously announced for September 10th.
At this point, I'm not aware of any reason to delay that date.  Are
there any Stage 2 patches that people don't think will be submitted by
that point?

Are there Stage 1 or Stage 2 patches in need of review?  I'll do my best
to either (a) convince someone to review them, or (b) review them myself.

Quality
=======

Priority   #
--------  ---
P1         43
P2        118
P3          4
Total     165

Obviously, that's rather more P1s than we'd like.  As I mentioned in my
previous status report, of particular concern is that we've got a lot of
4.3-only P1s.  I'm sure many of those won't be too hard to fix, but we
still need to go and fix them.

I'm concerned about getting into a situation where we say "well, 4.2 has
some bugs, but all of those are fixed in 4.3" and then realize that "oh,
well, 4.3 has different bugs too, but those are all fixed in 4.4" and so
forth.

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

http://gcc.gnu.org/ml/gcc/2007-08/msg00181.html

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

Re: GCC 4.3.0 Status Report (2007-09-04)

[DJ Delorie]

Mark Mitchell <mark@codesourcery.com> writes:
> Are there Stage 1 or Stage 2 patches in need of review?

Do you want the diagnostic pragma push/pop patch in?

Re: GCC 4.3.0 Status Report (2007-09-04)

[Mark Mitchell]

DJ Delorie wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
>> Are there Stage 1 or Stage 2 patches in need of review?
> 
> Do you want the diagnostic pragma push/pop patch in?

In, if it works. :-)  URL, please?

Thanks,

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

Re: GCC 4.3.0 Status Report (2007-09-04)

[DJ Delorie]

> In, if it works. :-)

Well, it does what it's supposed to do.  Whether that's a "works" in
the grand scheme of things is still debatable :-)

I'd still need to write testcases and a changelog, as I was posing it
as a what-if-example so far.

Also, we still don't guarantee proper operation in all cases if you
change diagnostics after defining a function.  That will have to wait
until we have the single-int-location thing.

Also, we never decided if "undo" was worth the extra overhead.  The
code is in the patch, but ifdef'd out.

> URL, please?

http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01317.html

Re: GCC 4.3.0 Status Report (2007-09-04)

[Mark Mitchell]

DJ Delorie wrote:

> Also, we never decided if "undo" was worth the extra overhead.  The
> code is in the patch, but ifdef'd out.
> 
>> URL, please?
> 
> http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01317.html

It looks to me like this probably isn't quite ready for prime-time; I do
think we'd want to make the push/pop stuff fully reliable, including
warnings emitted from the middle-end.  That's not an over-my-dead-body;
if other people feel differently, I'm happy to discuss.

Thanks,

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

Re: GCC 4.3.0 Status Report (2007-09-04)

[DJ Delorie]

> It looks to me like this probably isn't quite ready for prime-time;
> I do think we'd want to make the push/pop stuff fully reliable,
> including warnings emitted from the middle-end.

push-pop around functions won't be reliable until we have the file
location thing, so we can map a file:line to a point in the chain of
changes to the diagnostic classification tree.  This is no different
than our current disclaimer that pragma diagnostic changes after the
first function definition are not supported.

Re: GCC 4.3.0 Status Report (2007-09-04)

[Richard Guenther]

On 9/5/07, Mark Mitchell <mark@codesourcery.com> wrote:
> Summary
> =======
>
> We are closing in on Stage 3, previously announced for September 10th.
> At this point, I'm not aware of any reason to delay that date.  Are
> there any Stage 2 patches that people don't think will be submitted by
> that point?
>
> Are there Stage 1 or Stage 2 patches in need of review?  I'll do my best
> to either (a) convince someone to review them, or (b) review them myself.

There is

http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html

for example, which is not suitable for stage3.

Richard.

Re: GCC 4.3.0 Status Report (2007-09-04)

[Paolo Bonzini]

> There is
> 
> http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html
> 
> for example, which is not suitable for stage3.

As much as I like the idea, wasn't get_non_trapping considered unsafe?

Paolo

Re: GCC 4.3.0 Status Report (2007-09-04)

[Richard Guenther]

On 9/6/07, Paolo Bonzini <bonzini@gnu.org> wrote:
>
> > There is
> >
> > http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html
> >
> > for example, which is not suitable for stage3.
>
> As much as I like the idea, wasn't get_non_trapping considered unsafe?

Only if you tried to preserve this information across passes.  This updated
patch computes this information just for the local transformation.

Richard.

Re: GCC 4.3.0 Status Report (2007-09-04)

[Manuel López-Ibáñez]

On 05/09/07, Mark Mitchell <mark@codesourcery.com> wrote:
> Summary
> =======
>
> We are closing in on Stage 3, previously announced for September 10th.
> At this point, I'm not aware of any reason to delay that date.  Are
> there any Stage 2 patches that people don't think will be submitted by
> that point?
>
> Are there Stage 1 or Stage 2 patches in need of review?  I'll do my best
> to either (a) convince someone to review them, or (b) review them myself.
>

The patches to make the new -Wconversion work with decimal float types
are still pending review.
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01356.html

Unfortunately, even if I could skip sleep for one night to get some
extra time, I won't have the means needed to test them, update them to
current trunk or commit them before Sep 10th. Perhaps in two or three
weeks I could...

By the way, have the patches for FixedPointArithmetic added
Wconversion support? I guess that will make the patches above to not
apply cleanly anymore.

Cheers,

Manuel.

Re: GCC 4.3.0 Status Report (2007-09-04)

[Jan Hubicka]

> Summary
> =======
> 
> We are closing in on Stage 3, previously announced for September 10th.
> At this point, I'm not aware of any reason to delay that date.  Are
> there any Stage 2 patches that people don't think will be submitted by
> that point?

I am still planning to do some retuning of inliner (our inline limits
wasn't revisited for inclusion of SSA optimizers).  I am now waiting on
Diego to decide on
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00318.html
that makes the metrics looks quite significandly different.  Then I will
run few tests on our C++/SPEC tester in hope that we can now
significandly cut some of the limits previously pushed up by the tests
with large abstraction (DLV/Tramp3d) and speedup compilation/reduce
binaries.  It will probably take more than 2 days, but I hope it is
acceptable for early stage3. I will be on conference from 10th to 16th,
but I expect to be able to do the benchmarking needed.

Honza

Re: GCC 4.3.0 Status Report (2007-09-04)

[Sebastian Pop]

On 9/4/07, Mark Mitchell <mark@codesourcery.com> wrote:
> We are closing in on Stage 3, previously announced for September 10th.
> At this point, I'm not aware of any reason to delay that date.  Are
> there any Stage 2 patches that people don't think will be submitted by
> that point?
>

I still plan to submit the loop distribution pass.

Sebastian

RE: GCC 4.3.0 Status Report (2007-09-04)

[Fu, Chao-Ying]

Manuel López-Ibáñez wrote:
> 
> On 05/09/07, Mark Mitchell <mark@codesourcery.com> wrote:
> > Summary
> > =======
> >
> > We are closing in on Stage 3, previously announced for 
> September 10th.
> > At this point, I'm not aware of any reason to delay that date.  Are
> > there any Stage 2 patches that people don't think will be 
> submitted by
> > that point?
> >
> > Are there Stage 1 or Stage 2 patches in need of review?  
> I'll do my best
> > to either (a) convince someone to review them, or (b) 
> review them myself.
> >
> 
> The patches to make the new -Wconversion work with decimal float types
> are still pending review.
> http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01356.html
> 
> Unfortunately, even if I could skip sleep for one night to get some
> extra time, I won't have the means needed to test them, update them to
> current trunk or commit them before Sep 10th. Perhaps in two or three
> weeks I could...
> 
> By the way, have the patches for FixedPointArithmetic added
> Wconversion support? I guess that will make the patches above to not
> apply cleanly anymore.

  Not yet.  After I get the remaining patches (7, 8, 9, 10) checked in,
I will see how much work is needed to support Wconversion 
for fixed-point types.  Thanks!

Regards,
Chao-ying

RE: GCC 4.3.0 Status Report (2007-09-04)

[Jagasia, Harsha]

>On 9/4/07, Mark Mitchell <mark@codesourcery.com> wrote:
>> We are closing in on Stage 3, previously announced for September
10th.
>> At this point, I'm not aware of any reason to delay that date.  Are
>> there any Stage 2 patches that people don't think will be submitted
by
>> that point?
>>

I still plan to submit a patch for the x86 target cost model tuning. 

Harsha

Re: GCC 4.3.0 Status Report (2007-09-04)

[Martin Jambor]

Hi,

On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote:
> Summary
> =======
> 
> We are closing in on Stage 3, previously announced for September 10th.
> At this point, I'm not aware of any reason to delay that date.  Are
> there any Stage 2 patches that people don't think will be submitted by
> that point?
> 
> Are there Stage 1 or Stage 2 patches in need of review?  I'll do my best
> to either (a) convince someone to review them, or (b) review them myself.

Well, there's mine :-) Specifically, its the "Switch initializations
conversion:" http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00215.html

Jakub Jelinek had a few comments  and I changed the patch according to
them. After that,  nothing much happened. If any  maintainer likes the
patch, please commit it as I do not have write access to svn. OTOH, if
there are any further concerns, please let me know.

Sorry for a late reply, I lagged behind the mailing list for a few
days.

Thanks,

Martin

Re: GCC 4.3.0 Status Report (2007-09-04)

[Rask Ingemann Lambertsen]

On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote:
> Are there Stage 1 or Stage 2 patches in need of review?  I'll do my best
> to either (a) convince someone to review them, or (b) review them myself.

http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02217.html

It's blocking work on the additional optimization requested by the
"customer" in comment 11:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30315#c11

-- 
Rask Ingemann Lambertsen

Re: GCC 4.3.0 Status Report (2007-09-04)

[Mark Mitchell]

Martin Jambor wrote:

> Well, there's mine :-) Specifically, its the "Switch initializations
> conversion:" http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00215.html

Do you have an FSF copyright assignment on file?  This patch is big
enough that we would not be able to include it without that.

> Jakub Jelinek had a few comments  and I changed the patch according to
> them. After that,  nothing much happened. If any  maintainer likes the
> patch, please commit it as I do not have write access to svn. OTOH, if
> there are any further concerns, please let me know.

I see one technical change that should be made.  In particular, please
change:

> +/* We never create arrays larger than the following constant (given in number
> +   of elements).  */
> +#define MAX_ARRAY_RANGE 0x2000
> +
> +/* We never create arrays  if the number of branches is not  at least the range
> +   divided by the following constant.  */
> +#define MAX_RANGE_BRANCH_RATIO 8

to use the --param mechanism.  Our policy is to have *no* magic numbers
for these kinds of things.  It's easy enough to allow users to use
--param to set the values, and that makes it easy for people (often the
compiler developers themselves) to experiment with the values to help
fine-tune the defaults.

Other than that, the patch looks pretty good to me.  However, I'd like a
middle-end maintainer to review the patch.  Ian, Diego, Roger, would one
of you please take a look?

Is there any reason to think this patch might generate worse code on
some processors or in some modes?  For example, while this patch seems
it's definitely a code-size win for dense switch statements, do we need
some kind of cost model to tell us whether it's a code-size win with
less dense switch statements?  Do we want want separate params when
we're operating under -Os from when we're operating under -O2?

Thanks,

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

Re: GCC 4.3.0 Status Report (2007-09-04)

[Mark Mitchell]

Rask Ingemann Lambertsen wrote:
> On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote:
>> Are there Stage 1 or Stage 2 patches in need of review?  I'll do my best
>> to either (a) convince someone to review them, or (b) review them myself.
> 
> http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02217.html

This patch is OK.

There may be machine descriptions that, for whatever reason, only do
something clever with "a + b < b"; they will now lose.  But, those
machine descriptions were odd anyhow; logically, they should handle both
"a + b < a" and "a + b < b" the same way.

So, your patch seems like a good improvement; as you say, it gives the
back end fewer cases to optimize.

Thanks,

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

Re: GCC 4.3.0 Status Report (2007-09-04)

[Mark Mitchell]

Richard Guenther wrote:

> There is
> 
> http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html
> 
> for example, which is not suitable for stage3.

This is an optimization pass which leads to dramatically better code on
at least one SPEC benchmark.  Ian, Roger, Diego, would one of you care
to review this?

Thanks,

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

Re: GCC 4.3.0 Status Report (2007-09-04)

[Mark Mitchell]

Jan Hubicka wrote:

> I am still planning to do some retuning of inliner (our inline limits
> wasn't revisited for inclusion of SSA optimizers).

Assuming that the tuning is essentially twiddling constants, I'm not
overly worried.  If you're planning to adjust the algorithms
substantially, then I'd be more concerned.  Let me know.

Thanks!

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

Re: GCC 4.3.0 Status Report (2007-09-04)

[Mark Mitchell]

Jagasia, Harsha wrote:

> I still plan to submit a patch for the x86 target cost model tuning. 

Assuming that this isn't too dramatic, I'll leave approval of that
during Stage 3 to the x86 back-end maintainers.

Thanks,

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

Re: GCC 4.3.0 Status Report (2007-09-04)

[Roger Sayle]

> This is an optimization pass which leads to dramatically better code on

> at least one SPEC benchmark.  Ian, Roger, Diego, would one of you care
> to review this?

My concern is that as formulated, conditional store elimination is not 
always a win.

Transforming

    if (cond)
      *p = x;

into

  tmp = *p;
  if (cond)
    tmp = x;
  *p = tmp;

on it's own, effectively transforms a conditional write to memory into an 
unconditional write to memory.
On many platforms, even x86, this a pessimization.  For example, the "Intel 
Architecture Optimization Manual", available at 
ftp://download.intel.com/design/PentiumII/manuals/24281603.PDF in section 
3.5.5 "Write Allocation Effects", actually recommends the inverse 
transformation.  On page 3-21 they show how the "Sieve of Erastothenes" 
benchmark can be sped up on Pentium class processors by transforming the 
line

    array[j] = 0;

into the equivalent

    if (array[j] != 0)
      array[j] = 0;

i.e. by introducing conditional stores.


The significant observation with Michael Matz's extremely impressive 26% 
improvement on 456.hmmer is the interaction between this transformation with 
other passes, that allow the conditional store to be hoisted out of a 
critical loop.  By reading the value into a "tmp" before the loop, 
conditionally storing to the register tmp in the loop, then unconditionally 
writing the result back afterwards, we dramatically reduce the number of 
memory writes, rather than increase them as when this transformation is 
applied in isolation.


I think the correct fix is not to apply this transformation everywhere, but 
to correctly identify those loop cases where it helps and perform the loop 
transformation there.  i.e. conditional induction variable identification, 
hoisting and sinking needs to be improved instead of pessimizing code to a 
simpler form that allows our existing flawed passes to trigger.


I do very much like the loop-restricted version of this transformation, and 
it's impressive impact of HMMR (whose author Sean Eddy is a good friend). 
Perhaps Mark might give revised versions of this patch special dispensation 
to be applied in stage 3.  I'd not expect any correctness issues/bugs, just 
performance trade-offs that need to be investigated.  Perhaps we should even 
apply this patch as is during stage 2, and allow the potential non-loop 
performance degradations to be addressed as follow-up patches and therefore 
regression fixes suitable for stage 3?

Congratulations again to Michael for this impressive performance 
improvement.

Roger
--
Roger Sayle, Ph.D.
OpenEye Scientific Software,
Suite #D, 9 Bisbee Court,
Santa Fe, New Mexico, 87508.

Re: GCC 4.3.0 Status Report (2007-09-04)

[Richard Guenther]

On 9/9/07, Roger Sayle <roger@eyesopen.com> wrote:
>
> > This is an optimization pass which leads to dramatically better code on
>
> > at least one SPEC benchmark.  Ian, Roger, Diego, would one of you care
> > to review this?

Btw, diego already approved the patch.

> My concern is that as formulated, conditional store elimination is not
> always a win.
>
> Transforming
>
>     if (cond)
>       *p = x;
>
> into
>
>   tmp = *p;
>   if (cond)
>     tmp = x;
>   *p = tmp;
>
> on it's own, effectively transforms a conditional write to memory into an
> unconditional write to memory.

The pass currently only does the transformation if there is a preceding
load already.  Because I raised this same issue ;)

> On many platforms, even x86, this a pessimization.  For example, the "Intel
> Architecture Optimization Manual", available at
> ftp://download.intel.com/design/PentiumII/manuals/24281603.PDF in section
> 3.5.5 "Write Allocation Effects", actually recommends the inverse
> transformation.  On page 3-21 they show how the "Sieve of Erastothenes"
> benchmark can be sped up on Pentium class processors by transforming the
> line
>
>     array[j] = 0;
>
> into the equivalent
>
>     if (array[j] != 0)
>       array[j] = 0;
>
> i.e. by introducing conditional stores.

I suppose this is no longer true on modern processors?  I think the
pass may undo this case.  But I'm also not sure we should worry about
this.

> The significant observation with Michael Matz's extremely impressive 26%
> improvement on 456.hmmer is the interaction between this transformation with
> other passes, that allow the conditional store to be hoisted out of a
> critical loop.  By reading the value into a "tmp" before the loop,
> conditionally storing to the register tmp in the loop, then unconditionally
> writing the result back afterwards, we dramatically reduce the number of
> memory writes, rather than increase them as when this transformation is
> applied in isolation.
>
>
> I think the correct fix is not to apply this transformation everywhere, but
> to correctly identify those loop cases where it helps and perform the loop
> transformation there.  i.e. conditional induction variable identification,
> hoisting and sinking needs to be improved instead of pessimizing code to a
> simpler form that allows our existing flawed passes to trigger.
>
>
> I do very much like the loop-restricted version of this transformation, and
> it's impressive impact of HMMR (whose author Sean Eddy is a good friend).
> Perhaps Mark might give revised versions of this patch special dispensation
> to be applied in stage 3.  I'd not expect any correctness issues/bugs, just
> performance trade-offs that need to be investigated.  Perhaps we should even
> apply this patch as is during stage 2, and allow the potential non-loop
> performance degradations to be addressed as follow-up patches and therefore
> regression fixes suitable for stage 3?

I think it should be straight forward to apply this transformation in loops
only - requiring analysis that the resulting loads and stores are loop
invariant would of course require more work.

Given the above restriction we apply already, do you hold your
objections or would you consider the "simple" loop improvement?

Thanks,
Richard.

Re: GCC 4.3.0 Status Report (2007-09-04)

[Mark Mitchell]

Richard Guenther wrote:
> On 9/9/07, Roger Sayle <roger@eyesopen.com> wrote:
>>> This is an optimization pass which leads to dramatically better code on
>>> at least one SPEC benchmark.  Ian, Roger, Diego, would one of you care
>>> to review this?
> 
> Btw, diego already approved the patch.

I apologize for muddying the waters, then.  Roger, thank you for reviewing.

I'll leave Richard G., Roger, and Diego to work out what best to do;
please let me know if I can help.

Thanks,

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

Re: GCC 4.3.0 Status Report (2007-09-04)

[Jan Hubicka]

> Jan Hubicka wrote:
> 
> > I am still planning to do some retuning of inliner (our inline limits
> > wasn't revisited for inclusion of SSA optimizers).
> 
> Assuming that the tuning is essentially twiddling constants, I'm not
> overly worried.  If you're planning to adjust the algorithms
> substantially, then I'd be more concerned.  Let me know.

Thanks, the plan is to essentially twiddle the constants (reduce limits
since we now see more realistic program estimates).

There is similar situation with the currently discussed SSE conversion
codegen - I've comitted the basic codegen changes today, but we need to
run some benchmarks to figure out setting for generic model.  I hope
this would be acceptable too... CPU2006 takes a lot of time :(

Honza

Re: GCC 4.3.0 Status Report (2007-09-04)

[Jakub Jelinek]

On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote:
> We are closing in on Stage 3, previously announced for September 10th.
> At this point, I'm not aware of any reason to delay that date.  Are
> there any Stage 2 patches that people don't think will be submitted by
> that point?
> 
> Are there Stage 1 or Stage 2 patches in need of review?  I'll do my best
> to either (a) convince someone to review them, or (b) review them myself.

I have a bunch of tiny patches, nevertheless all Stage 2 material, as
they add new features:

__artificial__ attribute (except the builtins.c hunk which is addressed
differently):
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02300.html

__builtin_va_arg_pack_len () addition:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00675.html

redundant zero store elimination optimization (simplistic version,
but nevertheless is able to trigger many times during gcc bootstrap):
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00663.html

diagnostic changes to print virtual call stack:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00868.html

__error_decl__ and __warning_decl__ attributes:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00876.html

	Jakub

RE: GCC 4.3.0 Status Report (2007-09-04)

[Jagasia, Harsha]

>Jagasia, Harsha wrote:
>
>> I still plan to submit a patch for the x86 target cost model tuning.
>
>Assuming that this isn't too dramatic, I'll leave approval of that
>during Stage 3 to the x86 back-end maintainers.

Thanks.

The patch involves some x86 back-end bits, which Honza has already
approved and some fixes to the vectorizer, which Dorit has mostly
approved (I am waiting on her approval for my last mail).

My plan is to submit the patch today with the changes Dorit has
recommended.
I may end up splitting it such that most of the patch makes it today and
one bug fix for the vectorizer makes it in stage 3.

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

Re: GCC 4.3.0 Status Report (2007-09-04)

[Peter Bergner]

On Tue, 2007-09-04 at 19:40 -0700, Mark Mitchell wrote:
> Are there Stage 1 or Stage 2 patches in need of review?  I'll do my best
> to either (a) convince someone to review them, or (b) review them myself.

It has only been four days since I posted the patch, but I am
waiting for a review of the new interference graph representation:

  http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00529.html

In addition to the powerpc64-linux bootstrap and regtesting I
did, Seongbae bootstrapped and regtested this on x86_64 with
no regressions as well as running it on SPEC with no runtime
or compile time regressions.

Peter

Re: GCC 4.3.0 Status Report (2007-09-04)

[Michael Meissner]

On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote:
> Summary
> =======
> 
> We are closing in on Stage 3, previously announced for September 10th.
> At this point, I'm not aware of any reason to delay that date.  Are
> there any Stage 2 patches that people don't think will be submitted by
> that point?
> 
> Are there Stage 1 or Stage 2 patches in need of review?  I'll do my best
> to either (a) convince someone to review them, or (b) review them myself.
> 
> Quality
> =======
> 
> Priority   #
> --------  ---
> P1         43
> P2        118
> P3          4
> Total     165
> 
> Obviously, that's rather more P1s than we'd like.  As I mentioned in my
> previous status report, of particular concern is that we've got a lot of
> 4.3-only P1s.  I'm sure many of those won't be too hard to fix, but we
> still need to go and fix them.
> 
> I'm concerned about getting into a situation where we say "well, 4.2 has
> some bugs, but all of those are fixed in 4.3" and then realize that "oh,
> well, 4.3 has different bugs too, but those are all fixed in 4.4" and so
> forth.

One patch that got dropped on the floor was my patch to remove the dependency
in the back ends of the way arguments are encoded, so that eventually for LTO
we can swtich to using a vector instead of linked list.  As I recall, I had
fixed all backends except for the SPU, which I needed to investigate the
builtins.  Now that SSE5 is winding down, I can go back to this patch.  Given
it has been reviewed in this list, I will leave it to Mark to decide whether it
should go into 4.3 or 4.4.

-- 
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
michael.meissner@amd.com

Re: GCC 4.3.0 Status Report (2007-09-04)

[Martin Jambor]

Hi,

thanks for looking at the patch.

On Sun, Sep 09, 2007 at 11:42:55AM -0700, Mark Mitchell wrote:
> Martin Jambor wrote:
> 
> > Well, there's mine :-) Specifically, its the "Switch initializations
> > conversion:" http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00215.html
> 
> Do you have an FSF copyright assignment on file?  This patch is big
> enough that we would not be able to include it without that.

Yes, I do, see http://misc.jamborm.net/Jambor305799.pdf

> I see one technical change that should be made.  In particular, please
> change:
> 
> > +/* We never create arrays larger than the following constant (given in number
> > +   of elements).  */
> > +#define MAX_ARRAY_RANGE 0x2000
> > +
> > +/* We never create arrays  if the number of branches is not  at least the range
> > +   divided by the following constant.  */
> > +#define MAX_RANGE_BRANCH_RATIO 8
> 
> to use the --param mechanism.  Our policy is to have *no* magic numbers
> for these kinds of things.  It's easy enough to allow users to use
> --param to set the values, and that makes it easy for people (often the
> compiler developers themselves) to experiment with the values to help
> fine-tune the defaults.

OK, I have changed the patch accordingly (and added some documentation
that was missing  last time) and am currently  re-testing it. I expect
to post the new version to the list tonight.

Martin

Re: GCC 4.3.0 Status Report (2007-09-04)

[Mark Mitchell]

Jakub Jelinek wrote:

> I have a bunch of tiny patches, nevertheless all Stage 2 material, as
> they add new features:

I'd like a middle-end maintainer to review this one:

> redundant zero store elimination optimization (simplistic version,
> but nevertheless is able to trigger many times during gcc bootstrap):
> http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00663.html

That seems like a nice optimization.  It was interesting to see how many
places this hit in GCC.  I didn't see any data about performance
improvements on benchmarks (e.g., SPEC), or code-size improvements
(e.g., CSiBE), but it sure can't hurt.

Unfortunately, I think there are enough issues around most of the rest
of these patches that we should wait for 4.4.  In particular, all of these:

> __artificial__ attribute (except the builtins.c hunk which is addressed
> differently):
> http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02300.html
> 
> __builtin_va_arg_pack_len () addition:
> http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00675.html
> 
> __error_decl__ and __warning_decl__ attributes:
> http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00876.html

add extensions of one kind or another to GCC, and there has been some
discussion about each of them.  I think we have to be very careful with
these things; once they go out in a release, we live with them forever.

However, I do hereby acknowledge that these were submitted before Stage
2 ended, and, as per our guidelines, if these patches are approved, they
can still go in.

This one:

> diagnostic changes to print virtual call stack:
> http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00868.html

looks like it would have a major effect on consumers of GCC output.  As
you say:

> The tools that parse this will need changing anyway to do something
> reasonable with it

I think we should consider GCC diagnostic a defined, machine-readable
format and that we should modify it only in backwards-compatible ways.
Or, make incompatible changes only under control of an option or
environment variable.

Thanks,

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

Re: GCC 4.3.0 Status Report (2007-09-04)

[Mark Mitchell]

Peter Bergner wrote:
> On Tue, 2007-09-04 at 19:40 -0700, Mark Mitchell wrote:
>> Are there Stage 1 or Stage 2 patches in need of review?  I'll do my best
>> to either (a) convince someone to review them, or (b) review them myself.
> 
> It has only been four days since I posted the patch, but I am
> waiting for a review of the new interference graph representation:
> 
>   http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00529.html

This certainly seems an excellent thing.  If nobody else reviews this, I
will do so -- but I hope that one of our busy middle-end maintainers
will make time.

Thanks,

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

Re: GCC 4.3.0 Status Report (2007-09-04)

[Kai Tietz]

I have two patch may be worth to enter into 4.3 at stage 2.
Jan and I tried to ping the first part now about some time and we didn't 
got a comment or approval for them.

See
http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html
http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-attributes-in-i386-may-before-stage--3-tf4428449.html

Cheers,
 i.A. Kai Tietz

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

------------------------------------------------------------------------------------------
  OneVision Software Entwicklungs GmbH & Co. KG
  Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
  Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
  Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
  Handelsregister: HRA 6744, Amtsgericht Regensburg
  Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
  Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
  Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: 
Ulrike Döhler, Manuela Kluger

Re: GCC 4.3.0 Status Report (2007-09-04)

[Ramana Radhakrishnan]

Hi,

I apologize for the late response to your mail but I sort of did these
patches up recently .

I have a couple of patches that I submitted / intend to submit . One
of them was submitted today regarding a small improvement to the
auto-increment pass. I am not sure if this is suitable for stage3 if
it is approved.

http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01060.html

The other patch that we have for submission is relatively trivial and
tries to be more precise with size costs for builtins while inlining.
I guess that should be alright for stage3  .

cheers
Ramana




> We are closing in on Stage 3, previously announced for September 10th.
> At this point, I'm not aware of any reason to delay that date.  Are
> there any Stage 2 patches that people don't think will be submitted by
> that point?
>
> Are there Stage 1 or Stage 2 patches in need of review?  I'll do my best
> to either (a) convince someone to review them, or (b) review them myself.
>
> Quality
> =======
>
> Priority   #
> --------  ---
> P1         43
> P2        118
> P3          4
> Total     165
>
> Obviously, that's rather more P1s than we'd like.  As I mentioned in my
> previous status report, of particular concern is that we've got a lot of
> 4.3-only P1s.  I'm sure many of those won't be too hard to fix, but we
> still need to go and fix them.
>
> I'm concerned about getting into a situation where we say "well, 4.2 has
> some bugs, but all of those are fixed in 4.3" and then realize that "oh,
> well, 4.3 has different bugs too, but those are all fixed in 4.4" and so
> forth.
>
> Previous Report
> ===============
>
> http://gcc.gnu.org/ml/gcc/2007-08/msg00181.html
>
> --
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713
>


-- 
Ramana Radhakrishnan

Re: GCC 4.3.0 Status Report (2007-09-04)

[Mark Mitchell]

Kai Tietz wrote:

> See
> http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html
> http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-attributes-in-i386-may-before-stage--3-tf4428449.html

Thanks for letting me know.  I'm going to leave this to the x86 back-end
maintainers.

Thanks,

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

Re: GCC 4.3.0 Status Report (2007-09-04)

[Jan Hubicka]

> Kai Tietz wrote:
> 
> > See
> > http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html
> > http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-attributes-in-i386-may-before-stage--3-tf4428449.html
> 
> Thanks for letting me know.  I'm going to leave this to the x86 back-end
> maintainers.

The changes are not completely trivial, but it is easy to verify that
the default path (ie compiling sources not using new attributes) remains
unchanged, so I would be happy to review the i386 specific patch after
returning at Monday. Given also fact that this seems important for wine
and other hybrid environments.

Global or middle end maintainer is needed for the first patch however.

Honza
> 
> Thanks,
> 
> -- 
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2007-09-04)

[Mark Mitchell]

Michael Meissner wrote:

> One patch that got dropped on the floor was my patch to remove the dependency
> in the back ends of the way arguments are encoded, so that eventually for LTO
> we can swtich to using a vector instead of linked list. 

I think that could still goto 4.3, since it's already largely been
reviewed.  But, of course, we do need to make sure all the targets work.

Thanks,

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

Re: GCC 4.3.0 Status Report (2007-09-04)

[Mark Mitchell]

Ramana Radhakrishnan wrote:

> I have a couple of patches that I submitted / intend to submit . One
> of them was submitted today regarding a small improvement to the
> auto-increment pass. I am not sure if this is suitable for stage3 if
> it is approved.
> 
> http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01060.html

We know that auto-increment handling has gotten worse in GCC 4.2/4.3, so
if the relevant maintainers are happy with your patch from a technical
perspective, then I think it qualifies as a bug fix.

> The other patch that we have for submission is relatively trivial and
> tries to be more precise with size costs for builtins while inlining.
> I guess that should be alright for stage3  .

Yes, that sounds OK.

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

Re: GCC 4.3.0 Status Report (2007-09-04)

[Michael Meissner]

On Thu, Sep 13, 2007 at 10:45:56AM +0200, Jan Hubicka wrote:
> > Kai Tietz wrote:
> > 
> > > See
> > > http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html
> > > http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-attributes-in-i386-may-before-stage--3-tf4428449.html
> > 
> > Thanks for letting me know.  I'm going to leave this to the x86 back-end
> > maintainers.
> 
> The changes are not completely trivial, but it is easy to verify that
> the default path (ie compiling sources not using new attributes) remains
> unchanged, so I would be happy to review the i386 specific patch after
> returning at Monday. Given also fact that this seems important for wine
> and other hybrid environments.
> 
> Global or middle end maintainer is needed for the first patch however.

In the first patch, I am somewhat uncomfortable with changing RETURN_IN_MEMORY
and OUTGOING_REG_PARM_STACK_SPACE, by adding an additional parameter, and then
changing all of the targets.  It might be better to have new macros
(RETURN_IN_MEMORY_ABI, OUTGOING_REG_PARM_STACK_SPACE_ABI), and if the old macro
is defined, code the new macro calling the earlier macro.  This way you can
avoid changing the other backends.  Otherwise, you probably need to work with
each maintainer to make sure you haven't broken their code.

-- 
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
michael.meissner@amd.com

Re: GCC 4.3.0 Status Report (2007-09-04)

[Mark Mitchell]

Jan Hubicka wrote:
>> Kai Tietz wrote:
>>
>>> See
>>> http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html
>>> http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-attributes-in-i386-may-before-stage--3-tf4428449.html
>> Thanks for letting me know.  I'm going to leave this to the x86 back-end
>> maintainers.

> Global or middle end maintainer is needed for the first patch however.

Good point.

Kai, why is your change making OUTGOING_REG_PARM_STACK_SPACE accept a
FUNCTION_DECL, rather than a FUNCTION_TYPE?  I'd think that all
calling-convention predicates ought to be looking at the type to support
calling through function pointers?

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

RE: GCC 4.3.0 Status Report (2007-09-04)

[Meissner, Michael]

> -----Original Message-----
> From: Mark Mitchell [mailto:mark@codesourcery.com]
> Sent: Thursday, September 13, 2007 2:37 PM
> To: Meissner, Michael; Mark Mitchell; GCC
> Subject: Re: GCC 4.3.0 Status Report (2007-09-04)
> 
> Michael Meissner wrote:
> 
> > One patch that got dropped on the floor was my patch to remove the
> dependency
> > in the back ends of the way arguments are encoded, so that
eventually
> for LTO
> > we can swtich to using a vector instead of linked list.
> 
> I think that could still goto 4.3, since it's already largely been
> reviewed.  But, of course, we do need to make sure all the targets
work.

I didn't hear back from you, so I checked in the machine independent and
i386 parts in my SSE5 patch.  Now, on to making the various ports still
work with the change.

--
Michael Meissner
AMD, MS 83-29
90 Central Street
Boxborough, MA 01719

Re: GCC 4.3.0 Status Report (2007-09-04)

[Mark Mitchell]

Meissner, Michael wrote:

> I didn't hear back from you, so I checked in the machine independent and
> i386 parts in my SSE5 patch.  Now, on to making the various ports still
> work with the change.

All right; sounds good.

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

Re: GCC 4.3.0 Status Report (2007-09-04)

[Joseph S. Myers]

On Thu, 13 Sep 2007, Michael Meissner wrote:

> In the first patch, I am somewhat uncomfortable with changing RETURN_IN_MEMORY
> and OUTGOING_REG_PARM_STACK_SPACE, by adding an additional parameter, and then
> changing all of the targets.  It might be better to have new macros
> (RETURN_IN_MEMORY_ABI, OUTGOING_REG_PARM_STACK_SPACE_ABI), and if the old macro
> is defined, code the new macro calling the earlier macro.  This way you can
> avoid changing the other backends.  Otherwise, you probably need to work with
> each maintainer to make sure you haven't broken their code.

If you change the interface like that, the replacement should be a target 
hook in the target structure, not a target macro.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: GCC 4.3.0 Status Report (2007-09-04)

[Kai Tietz]

"Joseph S. Myers" wrote on 14.09.2007 00:09:49:

> On Thu, 13 Sep 2007, Michael Meissner wrote:
> 
> > In the first patch, I am somewhat uncomfortable with changing 
> RETURN_IN_MEMORY
> > and OUTGOING_REG_PARM_STACK_SPACE, by adding an additional 
> parameter, and then
> > changing all of the targets.  It might be better to have new macros
> > (RETURN_IN_MEMORY_ABI, OUTGOING_REG_PARM_STACK_SPACE_ABI), and if 
> the old macro
> > is defined, code the new macro calling the earlier macro.  This way 
you can
> > avoid changing the other backends.  Otherwise, you probably need 
> to work with
> > each maintainer to make sure you haven't broken their code.
> 
> If you change the interface like that, the replacement should be a 
target 
> hook in the target structure, not a target macro.
> 
On 14 August 2007 16:04, Kai Tietz wrote:

AFAICS is RETURN_IN_MEMORY deprecated, isn't it. It seems to be there just 
by an incomplete move to TARGET_RETURN_IN_MEMORY (which allready has the 
additional parameter). Here's the 3.3.3 internals manual:


10.10.9 How Large Values Are Returned
-------------------------------------

When a function value's mode is `BLKmode' (and in some other cases),
the value is not returned according to `FUNCTION_VALUE' (*note Scalar
Return::).  Instead, the caller passes the address of a block of memory
in which the value should be stored.  This address is called the
"structure value address".

   This section describes how to control returning structure values in
memory.

`RETURN_IN_MEMORY (TYPE)'
     A C expression which can inhibit the returning of certain function
     values in registers, based on the type of value.  A nonzero value
     says to return the function value in memory, just as large
     structures are always returned.  Here TYPE will be a C expression
     of type `tree', representing the data type of the value.

     Note that values of mode `BLKmode' must be explicitly handled by
     this macro.  Also, the option `-fpcc-struct-return' takes effect
     regardless of this macro.  On most systems, it is possible to
     leave the macro undefined; this causes a default definition to be
     used, whose value is the constant 1 for `BLKmode' values, and 0
     otherwise.

     Do not use this macro to indicate that structures and unions
     should always be returned in memory.  You should instead use
     `DEFAULT_PCC_STRUCT_RETURN' to indicate this.





  And now the current top-of-tree internals manual:




15.10.9 How Large Values Are Returned
-------------------------------------

When a function value's mode is `BLKmode' (and in some other cases),
the value is not returned according to `TARGET_FUNCTION_VALUE' (*note
Scalar Return::).  Instead, the caller passes the address of a block of
memory in which the value should be stored.  This address is called the
"structure value address".

 This section describes how to control returning structure values in
memory.

 -- Target Hook: bool TARGET_RETURN_IN_MEMORY (tree TYPE, tree FNTYPE)
     This target hook should return a nonzero value to say to return the
     function value in memory, just as large structures are always
     returned.  Here TYPE will be the data type of the value, and FNTYPE
     will be the type of the function doing the returning, or `NULL' for
     libcalls.

     Note that values of mode `BLKmode' must be explicitly handled by
     this function.  Also, the option `-fpcc-struct-return' takes
     effect regardless of this macro.  On most systems, it is possible
     to leave the hook undefined; this causes a default definition to
     be used, whose value is the constant 1 for `BLKmode' values, and 0
     otherwise.

     Do not use this hook to indicate that structures and unions should
     always be returned in memory.  You should instead use
     `DEFAULT_PCC_STRUCT_RETURN' to indicate this.





So it looks like the documentation is already there; this is an incomplete 
transition, and I am just bringing the old back-compat macros up-to-date 
with the changed abi for the new target-hook version!

Cheers,
 i.A. Kai Tietz

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

------------------------------------------------------------------------------------------
  OneVision Software Entwicklungs GmbH & Co. KG
  Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
  Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
  Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
  Handelsregister: HRA 6744, Amtsgericht Regensburg
  Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
  Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
  Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: 
Ulrike Döhler, Manuela Kluger

Re: GCC 4.3.0 Status Report (2007-09-04)

[Kai Tietz]

Mark Mitchell wrote on 13.09.2007 20:42:25:
> Jan Hubicka wrote:
> >> Kai Tietz wrote:
> >>
> >>> See
> >>> http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-
> MS-ABI-attributes-in-backend-tf4414541.html
> >>> http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-
> attributes-in-i386-may-before-stage--3-tf4428449.html
> >> Thanks for letting me know.  I'm going to leave this to the x86 
back-end
> >> maintainers.
> 
> > Global or middle end maintainer is needed for the first patch however.
> 
> Good point.
> 
> Kai, why is your change making OUTGOING_REG_PARM_STACK_SPACE accept a
> FUNCTION_DECL, rather than a FUNCTION_TYPE?  I'd think that all
> calling-convention predicates ought to be looking at the type to support
> calling through function pointers?

Hi Mark,

This macro is used also in builtin's and libcalls subject where the 
FUNC_DECL is a null reference. Also in most places the FUNC_DECL is 
allready present. To avoid duplicate code to check and get the FUNC_TYPE 
by FUNC_DECL, I choose to pass the function declaration.

Cheers,
 i.A. Kai Tietz

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

------------------------------------------------------------------------------------------
  OneVision Software Entwicklungs GmbH & Co. KG
  Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
  Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
  Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
  Handelsregister: HRA 6744, Amtsgericht Regensburg
  Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
  Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
  Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: 
Ulrike Döhler, Manuela Kluger

Re: GCC 4.3.0 Status Report (2007-09-04)

[Mark Mitchell]

Kai Tietz wrote:

>> Kai, why is your change making OUTGOING_REG_PARM_STACK_SPACE accept a
>> FUNCTION_DECL, rather than a FUNCTION_TYPE?  I'd think that all
>> calling-convention predicates ought to be looking at the type to support
>> calling through function pointers?
> 
> This macro is used also in builtin's and libcalls subject where the 
> FUNC_DECL is a null reference. Also in most places the FUNC_DECL is 
> allready present. To avoid duplicate code to check and get the FUNC_TYPE 
> by FUNC_DECL, I choose to pass the function declaration.

I'm sorry -- that doesn't really answer the question I was trying to
ask.  To be clear, if we're calling through a function pointer, we still
need to be able to do the right thing, and in that case we don't have a
FUNCTION_DECL.  So, I don't understand how you can have a macro to
control the calling convention that accepts a FUNCTION_DECL; I would
think it would have to accept a FUNCTION_TYPE.

Thanks,

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

Re: GCC 4.3.0 Status Report (2007-09-04)

[Kai Tietz]

Mark,

> Kai Tietz wrote:
> 
> >> Kai, why is your change making OUTGOING_REG_PARM_STACK_SPACE accept a
> >> FUNCTION_DECL, rather than a FUNCTION_TYPE?  I'd think that all
> >> calling-convention predicates ought to be looking at the type to 
support
> >> calling through function pointers?
> > 
> > This macro is used also in builtin's and libcalls subject where the 
> > FUNC_DECL is a null reference. Also in most places the FUNC_DECL is 
> > allready present. To avoid duplicate code to check and get the 
FUNC_TYPE 
> > by FUNC_DECL, I choose to pass the function declaration.
> 
> I'm sorry -- that doesn't really answer the question I was trying to
> ask.  To be clear, if we're calling through a function pointer, we still
> need to be able to do the right thing, and in that case we don't have a
> FUNCTION_DECL.  So, I don't understand how you can have a macro to
> control the calling convention that accepts a FUNCTION_DECL; I would
> think it would have to accept a FUNCTION_TYPE.

Sorry, I think I missed your question. To make the macro 
OUTGOING_REG_PARM_STACK_SPACE accepting a FUNCTION_DECL, there is no 
special reason for it. I deceided this to make it accepting a 
FUNCTION_DECL to avoid the fndecl to fntype conversion in middle-backend. 
In some cases there is no fntype nor a valid fndecl and (a NULL value), 
but there is the FUNCTION_DECL type allready present, therefore I choose 
the FUNCTION_DECL type instead of the FUNCTION_TYPE. I think, I used it to 
be according to the REG_PARM_STACK_SPACE macro. If this is a serious 
problem, of course I can move this to a FUNCTION_TYPE. Are there some 
special needs to have here FUNCTION_TYPE ?

Cheers,
 i.A. Kai Tietz

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

------------------------------------------------------------------------------------------
  OneVision Software Entwicklungs GmbH & Co. KG
  Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
  Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
  Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
  Handelsregister: HRA 6744, Amtsgericht Regensburg
  Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
  Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
  Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: 
Ulrike Döhler, Manuela Kluger

Re: GCC 4.3.0 Status Report (2007-09-04)

[Mark Mitchell]

Kai Tietz wrote:

>> I'm sorry -- that doesn't really answer the question I was trying to
>> ask.  To be clear, if we're calling through a function pointer, we still
>> need to be able to do the right thing, and in that case we don't have a
>> FUNCTION_DECL.  So, I don't understand how you can have a macro to
>> control the calling convention that accepts a FUNCTION_DECL; I would
>> think it would have to accept a FUNCTION_TYPE.
> 
> Sorry, I think I missed your question. To make the macro 
> OUTGOING_REG_PARM_STACK_SPACE accepting a FUNCTION_DECL, there is no 
> special reason for it. I deceided this to make it accepting a 
> FUNCTION_DECL to avoid the fndecl to fntype conversion in middle-backend. 

> If this is a serious
> problem, of course I can move this to a FUNCTION_TYPE. Are there some 
> special needs to have here FUNCTION_TYPE ?

Yes, I think this -- and any other macros/hooks that affect calling
convention -- must be based on FUNCTION_TYPEs, not FUNCTION_DECLs.
Otherwise, we cannot properly support calling through a function pointer.

From (one) type-theoretic perspective, types tell you what set of
operations you can perform.  You can't perform the operation "call this
function, putting its parameters in the usual place" if the function
doesn't want its parameters there; ergo, this must be a property of the
type.

Furthermore, I would argue that the attributes here should be recorded
*only* on the type, in order to avoid duplication.  That's not strictly
speaking necessary, but calling conventions are certainly properly
thought of as a property of types, not of declarations.

Thanks,

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

Re: GCC 4.3.0 Status Report (2007-09-04)

[Martin Jambor]

On Sun, Sep 09, 2007 at 11:42:55AM -0700, Mark Mitchell wrote:
> Other than that, the patch looks pretty good to me.  However, I'd like a
> middle-end maintainer to review the patch.  Ian, Diego, Roger, would one
> of you please take a look?

Well... ping? 

> to use the --param mechanism.  Our policy is to have *no* magic numbers
> for these kinds of things.  It's easy enough to allow users to use
> --param to set the values, and that makes it easy for people (often the
> compiler developers themselves) to experiment with the values to help
> fine-tune the defaults.

I have changed the patch accordingly, it can still be found at:

http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00972.html

Thanks,

Martin