headers
Raja R Harinath | 1 Mar 2003 01:11
Picon

Re: PATCH to toplevel Makefile.tpl

Hi,

DJ Delorie <dj <at> redhat.com> writes:

>> Which the top-level can't possibly solve except by using
>> .NOTPARALLEL.
>
> We also talked about a wrapper script that prevents simultaneous
> execution.  Has anyone talked to the autoconf folks about this
> problem?

The autoconf folks appear to have "solved" this by deprecating
config.cache: it defaults to /dev/null in configure scripts generated
by newer autoconfs.

- Hari
--

-- 
Raja R Harinath ------------------------------ harinath <at> cs.umn.edu
Permalink | Reply | 4 comments |
headers
Jan Hubicka | 1 Mar 2003 01:14
Picon

Re: [3.3/mainline] cleanup cfg only once when not optimizing

> On Fri, Feb 28, 2003 at 11:28:19AM +0100, Jan Hubicka wrote:
> > currently we call cleanup_cfg 4 times...
> 
> True, but wouldn't it make most sense to leave the last one
> and not the first one?  
Then a lot of code would bubble trought the compiler.
> 
> How does this affect compile times and object sizes on, say,
> a bootstrap with BOOT_CFLAGS=-O0?
I tried to compile combine.o and insn-attrtab.o and got exactly the same
files.  It saves about 4% on insn-attrtab.

Honza
> 
> 
> r~
Permalink | Reply | 1 comment |
headers
DJ Delorie | 1 Mar 2003 01:19
Picon
Favicon

Re: PATCH to toplevel Makefile.tpl


> The autoconf folks appear to have "solved" this by deprecating
> config.cache: it defaults to /dev/null in configure scripts
> generated by newer autoconfs.

That doesn't help us; we explicitly specify the cache (so that it can
be shared).
Permalink | Reply | 3 comments |
headers
Diego Novillo | 1 Mar 2003 01:22
Picon
Favicon

[tree-ssa] Copy propagation [patch]

I finally found time to adapt aldyh's copy propagation pass
(http://gcc.gnu.org/ml/gcc-patches/2002-11/msg01529.html).  Not
surprisingly, this patch looks quite different from the original.
The original implementation was done before we rewrote the base
infrastructure.

This is arguably one of the simplest optimization passes in SSA.
All it does is traverse the flowgraph looking for variable loads.
For every variable X_i, it checks its unique reaching definition.
If the definition is of the form X_i = Y_j, it replaces X_i with
Y_j.

As Aldy pointed out, copy propagation can make two different
versions of the same variable live at the same time.  For
instance,

	tmp_1 = y_1;
	if (...)
	  y_2 = ...
	z_3 = tmp_1;

Copy propagation will change the last assignment to 'z_3 = y_1'.
Since we do not yet have a real SSA->normal pass, when the
program is converted to normal form, GCC generates the following:

	tmp = y;
	if (...)
	  y = ...
	z = y;
(Continue reading)

Permalink | Reply | 20 comments |
headers
Mark Mitchell | 1 Mar 2003 01:28

Re: c++ failures

On Fri, 2003-02-28 at 13:17, John David Anglin wrote:
> Mark,
> 
> > Would you please add a PR for each new failure I caused, assign them to
> > me?  Then I promise I'll fix ASAP!
> 
> I will add a PR for the static9.C fail.  

I've got a patch for you to test in separate email.

> However, before we do all the others, could you look at
> 
> http://gcc.gnu.org/ml/gcc-patches/2003-02/msg02456.html

These have nothing to do with me.  You've gotten fooled because Aldy
checked in a patch with no cp/ChangeLog entry; the entry is in the
gcc/ChangeLog:

        * cp/parser.c (cp_parser_init_declarator): Call vector_opaque_p
        target hook.
        Include target.h.
        (cp_parser_init_declarator): Fix typo in function comments.

This patch is incorrect, and I can't find any mention of it in
gcc-patches -- which doesn't mean it wasn't there, just that I can't
find it.  Who approved this patch?

Aldy, would you please revert this patch?

The check you are trying to add should probably go in
(Continue reading)

Permalink | Reply | 11 comments |
headers
Jan Hubicka | 1 Mar 2003 01:26
Picon

Re: CFG merge part 7 - superblock/trace scheduling

> Jan Hubicka wrote:
> > 
> > > Hi,
> > > This patch adds option to enable superblock scheduling (aka EBB scheduler) for
> > > non-IA-64 targets as well as "trace scheduling" (aka EBB scheduler preceeded by
> > > the trace formation).
> > > My experience with this feature are bit mixed - by default it causes 2%
> > > regression on Athlon.  By significantly improving MD description I was able to
> > 
> > This regression seems to go away after changing the superblock choice
> > algorithm I sent in merge patch 11.
> 
> Jan, I've just checked trace scheduling on ia64 (intel itanium 900MHz
> server).  I needed to make some modifications for the compiler to switch
> it on for ia64.  It still has some test degradation but I managed to
How did you achieved that?
Do you run tracing before IA-64 MDEP_REORG?
> compile all SPECINT benchmarks except eon.  Unfortunately, there is no
> big improvement for code quality.  Here the results in brief are:
> 
>   o code quality improvement is 0.5% (Spec rate excluding eon is 406.38
> vs 404.52).
>   o slower compiler speed about 2% (user time is 11m27s vs 11m14s).
>   o bigger code about 20% (overall size of text segments is  9486Kb vs
> 7662Kb).
It should be possible to make tracer more conservative. There are
several knobs for that.  It has been tunned for pre-reload tracing to
improve CSE and the code growth is mostly elliminated by crossjumping
that does not happen after scheduling.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Richard Henderson | 1 Mar 2003 01:31
Picon
Favicon

Re: [3.3/mainline] cleanup cfg only once when not optimizing

On Sat, Mar 01, 2003 at 01:14:45AM +0100, Jan Hubicka wrote:
> I tried to compile combine.o and insn-attrtab.o and got exactly the same
> files.  It saves about 4% on insn-attrtab.

Hmm.  Ok then.

r~
Permalink | Reply | 0 comments |
headers
Richard Henderson | 1 Mar 2003 01:33
Picon
Favicon

Re: GCC 3.3 release criteria

On Thu, Feb 27, 2003 at 06:10:55PM -0800, Stuart Hastings wrote:
> As promised, and with the expectation it will be rejected ;-)

My feelings about this aren't that strong, and clearly there
are other people that want this.  I'll leave the decision to
some other global maintainer.

r~
Permalink | Reply | 0 comments |
headers
law | 1 Mar 2003 01:45
Picon
Favicon

Re: [tree-ssa] Copy propagation [patch]

In message <20030301002257.GA27233 <at> tornado.toronto.redhat.com>, Diego Novillo w
rites:
 >I finally found time to adapt aldyh's copy propagation pass
 >(http://gcc.gnu.org/ml/gcc-patches/2002-11/msg01529.html).  Not
 >surprisingly, this patch looks quite different from the original.
 >The original implementation was done before we rewrote the base
 >infrastructure.
 >
 >This is arguably one of the simplest optimization passes in SSA.
 >All it does is traverse the flowgraph looking for variable loads.
 >For every variable X_i, it checks its unique reaching definition.
 >If the definition is of the form X_i = Y_j, it replaces X_i with
 >Y_j.
 >
 >As Aldy pointed out, copy propagation can make two different
 >versions of the same variable live at the same time.  For
 >instance,
 >
 >	tmp_1 = y_1;
 >	if (...)
 >	  y_2 = ...
 >	z_3 = tmp_1;
 >
 >Copy propagation will change the last assignment to 'z_3 = y_1'.
 >Since we do not yet have a real SSA->normal pass, when the
 >program is converted to normal form, GCC generates the following:
 >
 >	tmp = y;
 >	if (...)
 >	  y = ...
(Continue reading)

Permalink | Reply | 17 comments |
headers
Gabriel Dos Reis | 1 Mar 2003 01:45

Re: c++ failures

Mark Mitchell <mark <at> codesourcery.com> writes:

| These have nothing to do with me.  You've gotten fooled because Aldy
| checked in a patch with no cp/ChangeLog entry; the entry is in the
| gcc/ChangeLog:

Thanks for the detective work!

-- Gaby
Permalink | Reply | 0 comments |

Gmane