Re: gomp slowness

[Jakub Jelinek]

On Fri, Nov 02, 2007 at 11:09:33PM -0700, Ian Lance Taylor wrote:
> skaller <[EMAIL PROTECTED]> writes:
> 
> > > As I said before, the register is only stolen for code which actually
> > > uses TLS.
> > 
> > So scanning that document, for x86_64, fs is used in startup
> > code, presumably if, and only if, there is a linker section
> > containing __thread variables?
> 
> Yes.

Well, at least on Linux given that libc uses it heavily internally and
also libpthread implementation uses that register (though different
area outside of what is used for __thread vars) for thread control
structure, this is "always".  On x86_64 %fs is simply part of ABI,
reserved register for implementation (similarly %gs on i386, other arches
usually have one or several registers reserved for implementation as well).
You can use another segment register, which is free for use by apps
(%gs on x86_64, %fs on i386) in your app, though of course note that for
changing it you need a syscall, so its use certainly isn't free.

Jakub

Re: gomp slowness

[Sylvain Pion]

skaller wrote :

I can tell you I definitely considered using FS for the
Felix thread frame pointer to save passing that pointer
between every function.. 


But then, won't you end up with an implementation very similar
to __thread??

--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/

Re: gomp slowness

[skaller]

On Sat, 2007-11-03 at 10:35 +0100, Sylvain Pion wrote:
> skaller wrote :
> > I can tell you I definitely considered using FS for the
> > Felix thread frame pointer to save passing that pointer
> > between every function.. 
> 
> But then, won't you end up with an implementation very similar
> to __thread??

Yes, but there are several differences:

1. Instead of reserving a fixed register in the ABI,
the compiler treats the pointer as an ordinary variable,
and so can apply ordinary optimisation procedures to it.

2. Because the application controls the data pointed at,
it need not be wasted on a resource which may not be needed,
and may have the option of using a subsuming data structure.

For example, if it pointed at the stack base which included
not only a pointer to TLS data but also other application
data, the cost of using the register would be relatively lower.

Felix does precisely this: one pointer to the 'thread-frame'
object includes not only a pointer to the garbage collector
(a system resource) but also arbitrary user data.

In a language with a display (Pascal, Ada, etc etc), the
display pointer can always find the stack base frame,
which can hold such data .. as well as locating
the rest of the current functions static environment
frames.

Now it is true C doesn't have a need for a general display.
However if C ABI/Compilers use a register for a specific,
rarely needed purpose, particularly supporting broken
legacy applications, that may interfere with more modern
advanced technology using the register more effectively.

My point really is: registers are a scarce resource,
and TLS is a broken subconcept of the more general
design error C commits, global store .. when a much
more general mechanism exists (static display) which
subsumes both.



-- 
John Skaller 
Felix, successor to C++: http://felix.sf.net

RE: Tree-SSA and POST_INC address mode inompatible in GCC4?

[Kenneth Zadeck]

I believe that this is something new and is most likely fallout from
diego's reworking of the tree to rtl converter.

To fix this will require a round of copy propagation, most likely in
concert with some induction variable detection, since the most
profitable place for this will be in loops.  

I wonder if any of this effects the rtl level induction variable
discovery?

> Hi, Ramana,
> I tried the trunk version  with/without your patch. It still produces
> the same code as gcc4.2.2 does. In auto-inc-dec.c, the comments say 
> 
>  *a
>...
>a <- a + c
> 
> becomes
> 
>*(a += c) post
> 
> But the problem is after Tree-SSA pass,  there is no
>a <- a + c
> But something like
>a_1 <- a + c
> 
> Unless the auto-inc-dec.c can reverse a_1 <- a + c to a <- a + c. I
> don't see this transformation is applicable in most scenarios. Any
> comments? 
> 
> Cheers,
> Bingfeng
> 

Re: Tree-SSA and POST_INC address mode inompatible in GCC4?

[Zdenek Dvorak]

Hi,

> I believe that this is something new and is most likely fallout from
> diego's reworking of the tree to rtl converter.
> 
> To fix this will require a round of copy propagation, most likely in
> concert with some induction variable detection, since the most
> profitable place for this will be in loops.  
> 
> I wonder if any of this effects the rtl level induction variable
> discovery?

it should not (iv analysis is able to deal with this kind of ivs).

Zdenek

> > Hi, Ramana,
> > I tried the trunk version  with/without your patch. It still produces
> > the same code as gcc4.2.2 does. In auto-inc-dec.c, the comments say 
> > 
> >  *a
> >...
> >a <- a + c
> > 
> > becomes
> > 
> >*(a += c) post
> > 
> > But the problem is after Tree-SSA pass,  there is no
> >a <- a + c
> > But something like
> >a_1 <- a + c
> > 
> > Unless the auto-inc-dec.c can reverse a_1 <- a + c to a <- a + c. I
> > don't see this transformation is applicable in most scenarios. Any
> > comments? 
> > 
> > Cheers,
> > Bingfeng
> > 

RE: Tree-SSA and POST_INC address mode inompatible in GCC4?

[J.C. Pizarro]

2007/11/3, Kenneth Zadeck wrote:
> I believe that this is something new and is most likely fallout from
> diego's reworking of the tree to rtl converter.
>
> To fix this will require a round of copy propagation, most likely in
> concert with some induction variable detection, since the most
> profitable place for this will be in loops.
>
> I wonder if any of this effects the rtl level induction variable
> discovery?
>
> > Hi, Ramana,
> > I tried the trunk version  with/without your patch. It still produces
> > the same code as gcc4.2.2 does. In auto-inc-dec.c, the comments say
> >
> >  *a
> >...
> >a <- a + c
> >
> > becomes
> >
> >*(a += c) post
> >
> > But the problem is after Tree-SSA pass,  there is no
> >a <- a + c
> > But something like
> >a_1 <- a + c
> >
> > Unless the auto-inc-dec.c can reverse a_1 <- a + c to a <- a + c. I
> > don't see this transformation is applicable in most scenarios. Any
> > comments?
> >
> > Cheers,
> > Bingfeng

They need to add an algorithm post-SSA that the code reuse the variables
converting a_j <- phi(a_i,...) to a_k <- phi(a_k,...).

The algorithms of POST_INC and POST_DEC are very specific, so an above
general algorithm is sufficient.

   J.C. Pizarro

Re: Tree-SSA and POST_INC address mode inompatible in GCC4?

[Kenneth Zadeck]

Zdenek Dvorak wrote:
> Hi,
>
>   
>> I believe that this is something new and is most likely fallout from
>> diego's reworking of the tree to rtl converter.
>>
>> To fix this will require a round of copy propagation, most likely in
>> concert with some induction variable detection, since the most
>> profitable place for this will be in loops.  
>>
>> I wonder if any of this effects the rtl level induction variable
>> discovery?
>> 
>
> it should not (iv analysis is able to deal with this kind of ivs).
>
> Zdenek
>
>   
does the iv analysis canonize them in a way that we should perhaps
consider moving the auto-inc detection after the iv analysis?
>>> Hi, Ramana,
>>> I tried the trunk version  with/without your patch. It still produces
>>> the same code as gcc4.2.2 does. In auto-inc-dec.c, the comments say 
>>>
>>>  *a
>>>...
>>>a <- a + c
>>>
>>> becomes
>>>
>>>*(a += c) post
>>>
>>> But the problem is after Tree-SSA pass,  there is no
>>>a <- a + c
>>> But something like
>>>a_1 <- a + c
>>>
>>> Unless the auto-inc-dec.c can reverse a_1 <- a + c to a <- a + c. I
>>> don't see this transformation is applicable in most scenarios. Any
>>> comments? 
>>>
>>> Cheers,
>>> Bingfeng
>>>
>>>   

Re: Tree-SSA and POST_INC address mode inompatible in GCC4?

[Kenneth Zadeck]

J.C. Pizarro wrote:
> 2007/11/3, Kenneth Zadeck wrote:
>   
>> I believe that this is something new and is most likely fallout from
>> diego's reworking of the tree to rtl converter.
>>
>> To fix this will require a round of copy propagation, most likely in
>> concert with some induction variable detection, since the most
>> profitable place for this will be in loops.
>>
>> I wonder if any of this effects the rtl level induction variable
>> discovery?
>>
>> 
>>> Hi, Ramana,
>>> I tried the trunk version  with/without your patch. It still produces
>>> the same code as gcc4.2.2 does. In auto-inc-dec.c, the comments say
>>>
>>>  *a
>>>...
>>>a <- a + c
>>>
>>> becomes
>>>
>>>*(a += c) post
>>>
>>> But the problem is after Tree-SSA pass,  there is no
>>>a <- a + c
>>> But something like
>>>a_1 <- a + c
>>>
>>> Unless the auto-inc-dec.c can reverse a_1 <- a + c to a <- a + c. I
>>> don't see this transformation is applicable in most scenarios. Any
>>> comments?
>>>
>>> Cheers,
>>> Bingfeng
>>>   
>
> They need to add an algorithm post-SSA that the code reuse the variables
> converting a_j <- phi(a_i,...) to a_k <- phi(a_k,...).
>
> The algorithms of POST_INC and POST_DEC are very specific, so an above
> general algorithm is sufficient.
>
>J.C. Pizarro
>   
This is a little too simple.  It assumes that the tree passes did
nothing.  In fact you want to try to discover what the induction
variables are and rewrite them into a canonical form that auto-inc-dec
can then pick up on.

Re: Tree-SSA and POST_INC address mode inompatible in GCC4?

[J.C. Pizarro]

2007/11/3, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
> They need to add an algorithm post-SSA that the code reuse the variables
> converting a_j <- phi(a_i,...) to a_k <- phi(a_k,...).

I'm sorry, "a_k <- phi(a_k,...)" is invalid due to SSA form definition,
but this algorithm need some form to represent it, e.g. SSA-extended.

   J.C. Pizarro

Re: Tree-SSA and POST_INC address mode inompatible in GCC4?

[J.C. Pizarro]

2007/11/3, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> J.C. Pizarro wrote:
> > They need to add an algorithm post-SSA that the code reuse the variables
> > converting a_j <- phi(a_i,...) to a_k <- phi(a_k,...).
> >
> > The algorithms of POST_INC and POST_DEC are very specific, so an above
> > general algorithm is sufficient.
>
> This is a little too simple.  It assumes that the tree passes did
> nothing.  In fact you want to try to discover what the induction
> variables are and rewrite them into a canonical form that auto-inc-dec
> can then pick up on.

The general algorithm is not simple, it has to explore and to reorganize
the complex graph, and can fall to conflicts.

   J.C. Pizarro

GNAT is required to build ada

[Jack Howarth]

  Is an external copy of GNAT really required to build the
ada language in gcc trunk? On powerpc-apple-darwin9, I am
seeing configure fail with...

configure: error: GNAT is required to build ada

...when ada is added to the language set. Certainly
this isn't the desired behavior.
  Jack

Re: GNAT is required to build ada

[Arnaud Charlet]

>   Is an external copy of GNAT really required to build the
> ada language in gcc trunk? On powerpc-apple-darwin9, I am
> seeing configure fail with...
> 
> configure: error: GNAT is required to build ada

Yes, that's the expected and documented behavior.

Arno

Re: Tree-SSA and POST_INC address mode inompatible in GCC4?

[Zdenek Dvorak]

Hi,

> >> I believe that this is something new and is most likely fallout from
> >> diego's reworking of the tree to rtl converter.
> >>
> >> To fix this will require a round of copy propagation, most likely in
> >> concert with some induction variable detection, since the most
> >> profitable place for this will be in loops.  
> >>
> >> I wonder if any of this effects the rtl level induction variable
> >> discovery?
> >> 
> >
> > it should not (iv analysis is able to deal with this kind of ivs).
> >
> does the iv analysis canonize them in a way that we should perhaps
> consider moving the auto-inc detection after the iv analysis?

no, iv analysis does not change the program; also, since the code in
this particular example is not in any loop, iv analysis is somewhat
irrelevant for it.

Btw.  I would have actually expected this code to be folded to

 *a_3(D) = D.1543_2;
  a_4 = a_3(D) + 1;
  b_5 = b_1(D) + 1;
  D.1543_6 = *b_5;
  *a_4 = D.1543_6;
  a_7 = a_3 + 2;
  b_8 = b_1 + 2;
  D.1543_9 = *b_8;
  *a_7 = D.1543_9;
  a_10 = a_3 + 3;
  b_11 = b_1 + 3;
  D.1543_12 = *b_11;
  *a_10 = D.1543_12;
  a_13 = a_3 + 4;
  b_14 = b_1 + 4;
  D.1543_15 = *b_14;
  *a_13 = D.1543_15;

etc.; I am fairly sure we used to do this.

Zdenek

Re: GNAT is required to build ada

[Robert Dewar]

Jack Howarth wrote:

  Is an external copy of GNAT really required to build the
ada language in gcc trunk? On powerpc-apple-darwin9, I am
seeing configure fail with...

configure: error: GNAT is required to build ada

...when ada is added to the language set. Certainly
this isn't the desired behavior.


GNAT is written in Ada, so you need an Ada compiler to
start a build, just as you need a C compiler to build
the C compiler.

  Jack

RE: Tree-SSA and POST_INC address mode inompatible in GCC4?

[Bingfeng Mei]

Yes, that is the better way to generate code than using POST_INC since
it eliminates unnecessary dependency. Which version used to do this?
Where should it be done? I am thinking one of those copy propagation
passes. Am I right?

Cheers,
Bingfeng

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Zdenek Dvorak
Sent: 03 November 2007 15:27
To: Kenneth Zadeck
Cc: gcc@gcc.gnu.org
Subject: Re: Tree-SSA and POST_INC address mode inompatible in GCC4?

Hi,

> >> I believe that this is something new and is most likely fallout
from
> >> diego's reworking of the tree to rtl converter.
> >>
> >> To fix this will require a round of copy propagation, most likely
in
> >> concert with some induction variable detection, since the most
> >> profitable place for this will be in loops.  
> >>
> >> I wonder if any of this effects the rtl level induction variable
> >> discovery?
> >> 
> >
> > it should not (iv analysis is able to deal with this kind of ivs).
> >
> does the iv analysis canonize them in a way that we should perhaps
> consider moving the auto-inc detection after the iv analysis?

no, iv analysis does not change the program; also, since the code in
this particular example is not in any loop, iv analysis is somewhat
irrelevant for it.

Btw.  I would have actually expected this code to be folded to

 *a_3(D) = D.1543_2;
  a_4 = a_3(D) + 1;
  b_5 = b_1(D) + 1;
  D.1543_6 = *b_5;
  *a_4 = D.1543_6;
  a_7 = a_3 + 2;
  b_8 = b_1 + 2;
  D.1543_9 = *b_8;
  *a_7 = D.1543_9;
  a_10 = a_3 + 3;
  b_11 = b_1 + 3;
  D.1543_12 = *b_11;
  *a_10 = D.1543_12;
  a_13 = a_3 + 4;
  b_14 = b_1 + 4;
  D.1543_15 = *b_14;
  *a_13 = D.1543_15;

etc.; I am fairly sure we used to do this.

Zdenek

Re: Tree-SSA and POST_INC address mode inompatible in GCC4?

[Richard Guenther]

On 11/3/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> Hi,
>
> > >> I believe that this is something new and is most likely fallout from
> > >> diego's reworking of the tree to rtl converter.
> > >>
> > >> To fix this will require a round of copy propagation, most likely in
> > >> concert with some induction variable detection, since the most
> > >> profitable place for this will be in loops.
> > >>
> > >> I wonder if any of this effects the rtl level induction variable
> > >> discovery?
> > >>
> > >
> > > it should not (iv analysis is able to deal with this kind of ivs).
> > >
> > does the iv analysis canonize them in a way that we should perhaps
> > consider moving the auto-inc detection after the iv analysis?
>
> no, iv analysis does not change the program; also, since the code in
> this particular example is not in any loop, iv analysis is somewhat
> irrelevant for it.
>
> Btw.  I would have actually expected this code to be folded to
>
>  *a_3(D) = D.1543_2;
>   a_4 = a_3(D) + 1;
>   b_5 = b_1(D) + 1;
>   D.1543_6 = *b_5;
>   *a_4 = D.1543_6;
>   a_7 = a_3 + 2;
>   b_8 = b_1 + 2;
>   D.1543_9 = *b_8;
>   *a_7 = D.1543_9;
>   a_10 = a_3 + 3;
>   b_11 = b_1 + 3;
>   D.1543_12 = *b_11;
>   *a_10 = D.1543_12;
>   a_13 = a_3 + 4;
>   b_14 = b_1 + 4;
>   D.1543_15 = *b_14;
>   *a_13 = D.1543_15;
>
> etc.; I am fairly sure we used to do this.

I guess FRE did this in former times.  While current VN figures this out,
it doesn't do the replacement:

Value numbering a_10 stmt = a_10 = a_7 + 1;
RHS a_7 + 1 simplified to a_3(D) + 3 has constants 0
Setting value number of a_10 to a_10

Danny, is this an oversight?

Richard.

Re: GNAT is required to build ada

[Gerald Pfeifer]

On Sat, 3 Nov 2007, Arnaud Charlet wrote:
>> configure: error: GNAT is required to build ada
> Yes, that's the expected and documented behavior.

Jack, we tried to write this down in the step-by-step instructions
you'll find at .  Is there anything we
could do to improve our documentation?

Gerald

Re: undocumented optimization options

[Gerald Pfeifer]

On Thu, 1 Nov 2007, Janis Johnson wrote:
>   -fipa-cp   steven
>   -fipa-matrix-reorg razya
>   -fipa-pure-const   zadeck  (enabled with -O)
>   -fipa-referencezadeck  (enabled with -O)
>   -fipa-type-escape  zadeck
>   -fvar-tracking-uninit  ctice
> 
> Is there a policy about whether an experimental option can be left
> undocumented, or should it be documented with a statement that it is
> experimental?

I'd prefer the latter.  And for options enabled by default or via one
of the commonly used options (such as -O) I believe we should always
include documentation _or_ we might want to remove those options and
make the associated active unconditionally.

> If an option is left undocumented on purpose then its entry in 
> common.opt should include "Undocumented".

So far we don't seem to use that in common.opt.

Gerald

Re: GNAT is required to build ada

[Toon Moene]

Jack Howarth wrote:


  Is an external copy of GNAT really required to build the
ada language in gcc trunk? On powerpc-apple-darwin9, I am
seeing configure fail with...

configure: error: GNAT is required to build ada

...when ada is added to the language set.


To wit: Debian "testing" doesn't include GNAT in it's gcc-4.2.3 version 
either.


Don't know why, however.

Kind regards,

--
Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.indiv.nluug.nl/~toon/
GNU Fortran's path to Fortran 2003: http://gcc.gnu.org/wiki/Fortran2003

Re: GNAT is required to build ada

[Richard Guenther]

On 11/3/07, Toon Moene <[EMAIL PROTECTED]> wrote:
> Jack Howarth wrote:
>
> >   Is an external copy of GNAT really required to build the
> > ada language in gcc trunk? On powerpc-apple-darwin9, I am
> > seeing configure fail with...
> >
> > configure: error: GNAT is required to build ada
> >
> > ...when ada is added to the language set.
>
> To wit: Debian "testing" doesn't include GNAT in it's gcc-4.2.3 version
> either.
>
> Don't know why, however.

Because it doesn't build on all required archs.  See
http://packages.qa.debian.org/g/gnat-4.2.html

But using the 4.1 version should be enough for bootstrapping.

Richard.

Re: GNAT is required to build ada

[Toon Moene]

Richard Guenther wrote:


On 11/3/07, Toon Moene <[EMAIL PROTECTED]> wrote:



To wit: Debian "testing" doesn't include GNAT in it's gcc-4.2.3 version
either.

Don't know why, however.


Because it doesn't build on all required archs.  See
http://packages.qa.debian.org/g/gnat-4.2.html

But using the 4.1 version should be enough for bootstrapping.


Hmmm, OK.  I confess that I'm not in need of an ADA compiler *that* much 
that I'm gonna find out how to bootstrap on Debian testing using a 
non-default GCC compiler ...


But to each his own ...

Kind regards,

--
Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.indiv.nluug.nl/~toon/
GNU Fortran's path to Fortran 2003: http://gcc.gnu.org/wiki/Fortran2003

Re: undocumented optimization options

[Steven Bosscher]

On 11/1/07, Janis Johnson <[EMAIL PROTECTED]> wrote:
> Several options reported by --help=optimize are not documented in the
> GCC Manual (via invoke.texi) but are still reported with
> --help=optimize,^undocumented.  Here are the options along with the
> people who checked in the entries to common.opt:
>
>   -fipa-cp   steven

I may have moved it around, I don't recall. But I did not add this option.
Gr.
Steven

Re: GNAT is required to build ada

[David Miller]

From: Robert Dewar <[EMAIL PROTECTED]>
Date: Sat, 03 Nov 2007 11:40:34 -0400

> Jack Howarth wrote:
> >   Is an external copy of GNAT really required to build the
> > ada language in gcc trunk? On powerpc-apple-darwin9, I am
> > seeing configure fail with...
> > 
> > configure: error: GNAT is required to build ada
> > 
> > ...when ada is added to the language set. Certainly
> > this isn't the desired behavior.
> 
> GNAT is written in Ada, so you need an Ada compiler to
> start a build, just as you need a C compiler to build
> the C compiler.

But we don't need a fortran compiler to compile the gfortran compiler,
and we don't need a c++ compiler to compile the g++ compiler, and we
don't even need a java compiler to compile the gcj compiler.

Sorry, I just couldn't resist.  This justification for the ADA
situation is just about as absurd as it gets :)

It really doesn't surprise me that users consider this extremely
awkward.  Even C# runtimes like MONO provide a way to bootstrap even
if you do not have any C# compiler at all available on your system.

Re: GNAT is required to build ada

[Robert Dewar]

David Miller wrote:


But we don't need a fortran compiler to compile the gfortran compiler,
and we don't need a c++ compiler to compile the g++ compiler, and we
don't even need a java compiler to compile the gcj compiler.


That's because they are written in C


Sorry, I just couldn't resist.  This justification for the ADA
situation is just about as absurd as it gets :)


Well the GNAT front end is written in Ada, there is no magic
available for compiling Ada without an Ada compiler!


It really doesn't surprise me that users consider this extremely
awkward.  Even C# runtimes like MONO provide a way to bootstrap even
if you do not have any C# compiler at all available on your system.


Well as long as you have a C compiler to compile g++, you can obviously
deal with C++ code, but there is no getting around that for GNAT
given that the front end is coded in Ada!

Re: GNAT is required to build ada

[David Miller]

From: Robert Dewar <[EMAIL PROTECTED]>
Date: Sat, 03 Nov 2007 18:40:56 -0400

> David Miller wrote:
> 
> > But we don't need a fortran compiler to compile the gfortran compiler,
> > and we don't need a c++ compiler to compile the g++ compiler, and we
> > don't even need a java compiler to compile the gcj compiler.
> 
> That's because they are written in C

The MONO C# compiler is written in C#, and amazingly they make it work
somehow that you can bootstrap without having a C# compiler.

> > Sorry, I just couldn't resist.  This justification for the ADA
> > situation is just about as absurd as it gets :)
> 
> Well the GNAT front end is written in Ada, there is no magic
> available for compiling Ada without an Ada compiler!

You can do it, MONO C# can.

> Well as long as you have a C compiler to compile g++, you can obviously
> deal with C++ code, but there is no getting around that for GNAT
> given that the front end is coded in Ada!

MONO can do it, so could ADA.

The trick is to have a program that, even if massively suboptimal, can
compile ADA code for the purposes of bootstrapping the ADA compiler
and is written in C.

Re: GNAT is required to build ada

[J.C. Pizarro]

On 2007/11/3, "David Miller"  wrote:
> The trick is to have a program that, even if massively suboptimal, can
> compile ADA code for the purposes of bootstrapping the ADA compiler
> and is written in C.

There are many tricks.

A) Works gnats from gcc-2.93.3? gcc-3.4.6? ...
B) Anyone has to compile .ads with -S option to get assembly .S files
and to upload to the svn/cvs tree for bootstrapping.
C) Google.

   J.C. Pizarro

Re: Results of 7z-4.55 performance with current GCCs.

[Ted Byers]

--- David Miller <[EMAIL PROTECTED]> wrote:

> From: NightStrike <[EMAIL PROTECTED]>
> Date: Fri, 2 Nov 2007 10:42:01 -0400
> 
> > I agree with you 100%.  It has always been my view
> that if you can't
> > compile fast enough, then get another machine and
> use distcc, or get a
> > quad core and do make -j5, etc etc.
> 
> I have 64 cpu machines and use make -j64, it's still
> not fast enough
> and I know it could be much faster.
> 
> Note that a faster GCC would also make GCC
> development go
> significantly quicker, since every developer has to
> do a full
> bootstrap and regression run before checking in
> non-trivial changes.
> 
> The world is not black and white, it is shades of
> gray.  Compilation
> time matters to some people, and I'm not in the
> slightest suggesting
> that it should trump code correctness.  I don't know
> where anyone got
> that idea from what I've been saying.
> 

I don't think anyone got that idea about your
position, but I have repeatedly seen posts about the
performance of tools, some emphasizing that the speed
of a compile is the top priority.  I just can't find,
right now, the post that was most emphatic about the
speed of compilation taking priority over all else. 
Maybe it is noise from other threads, possibly in
other lists I read, and then I see the post from the
OP about compiles that run to completion in mere
minutes.  Maybe that was the trigger that compelled me
to write about correctness trumping all else, and
other options for being productive when complete
builds take a while.  And I agreed with you that much
in the weighting of priorities is situation dependant.

On a different note, I wish I had your budget for
hardware.  :-)  With the kind of work I find most
interesting, one can never have too much hardware to
throw at a problem, and you all too easily start
hitting your head on the limits of of whatever
hardware you do have.  I know people that set up
computing clusters, with outrageously expensive
machines (relative to my budget) along with terabyte
data storage solutions, and still their environmental
models take weeks to finish.  And then the programs
required to analyze the data produced are even more
demanding.  There simply are problems I, and my peers,
would like to tackle but the computational resources
available are simply too constrainted to make an
attempt with the most defensible models without
greatly simplifying the models to be used.  Is such a
situation, the time taken by the development tools is
nothing.  But I can see others who answer to bean
counters who would place more priority on the speed of
the development tools and the impact that has on
programmer productivity.

I apologize if what I wrote created an incorrect
impression of what you had to say.  That was not what
intended.

Ted

Re: Tree-SSA and POST_INC address mode inompatible in GCC4?

[Daniel Berlin]

On 11/3/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On 11/3/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > > >> I believe that this is something new and is most likely fallout from
> > > >> diego's reworking of the tree to rtl converter.
> > > >>
> > > >> To fix this will require a round of copy propagation, most likely in
> > > >> concert with some induction variable detection, since the most
> > > >> profitable place for this will be in loops.
> > > >>
> > > >> I wonder if any of this effects the rtl level induction variable
> > > >> discovery?
> > > >>
> > > >
> > > > it should not (iv analysis is able to deal with this kind of ivs).
> > > >
> > > does the iv analysis canonize them in a way that we should perhaps
> > > consider moving the auto-inc detection after the iv analysis?
> >
> > no, iv analysis does not change the program; also, since the code in
> > this particular example is not in any loop, iv analysis is somewhat
> > irrelevant for it.
> >
> > Btw.  I would have actually expected this code to be folded to
> >
> >  *a_3(D) = D.1543_2;
> >   a_4 = a_3(D) + 1;
> >   b_5 = b_1(D) + 1;
> >   D.1543_6 = *b_5;
> >   *a_4 = D.1543_6;
> >   a_7 = a_3 + 2;
> >   b_8 = b_1 + 2;
> >   D.1543_9 = *b_8;
> >   *a_7 = D.1543_9;
> >   a_10 = a_3 + 3;
> >   b_11 = b_1 + 3;
> >   D.1543_12 = *b_11;
> >   *a_10 = D.1543_12;
> >   a_13 = a_3 + 4;
> >   b_14 = b_1 + 4;
> >   D.1543_15 = *b_14;
> >   *a_13 = D.1543_15;
> >
> > etc.; I am fairly sure we used to do this.
>
> I guess FRE did this in former times.  While current VN figures this out,
> it doesn't do the replacement:
>
> Value numbering a_10 stmt = a_10 = a_7 + 1;
> RHS a_7 + 1 simplified to a_3(D) + 3 has constants 0
> Setting value number of a_10 to a_10
>
> Danny, is this an oversight?

FRE currently will only try to replace with an existing SSA_NAME, not
with an expression.

It probably should, since it will help eliminate dead code if it does.

Re: GNAT is required to build ada

[Robert Dewar]

David Miller wrote:


The trick is to have a program that, even if massively suboptimal, can
compile ADA code for  the purposes of bootstrapping the ADA compiler
and is written in C.


No trick here, Ada is a complex language and even a "simple" Ada
compiler that you envision is a huge amount of work, but if you
feel it is practical, by all means go ahead and create such a beast!

Re: GNAT is required to build ada

[Robert Dewar]

Robert Dewar wrote:


No trick here, Ada is a complex language and even a "simple" Ada
compiler that you envision is a huge amount of work, but if you
feel it is practical, by all means go ahead and create such a beast!


By the way, early on we thought quite a bit about how to bootstrap
from C (there are other more practical ways, e.g. use a simulator
for MIPS or some other machine, or generate junk C from the back
end or ...) However, we quickly found that the cross-compilation
capabilities of gcc meant that in practice people could succeed
in creating ports for all kinds of strange machines, and it was
rapidly apparent that the amount of effort to "solve" this
problem was simply not worth it.

We do make sure to maintain compatibility with relatively ancient
versions of GNAT for bootstrapping purposes, which means that in
practice it is pretty easy to find a version of GNAT to start from
on most machines.

Re: Results of 7z-4.55 performance with current GCCs.

[David Miller]

From: Ted Byers <[EMAIL PROTECTED]>
Date: Sat, 3 Nov 2007 21:32:43 -0400 (EDT)

> On a different note, I wish I had your budget for
> hardware.  :-)

What budget?

These systems sit right at here with me at home, and I got all of them
for free.

Re: Results of 7z-4.55 performance with current GCCs.

[Ted Byers]

--- David Miller <[EMAIL PROTECTED]> wrote:
> From: Ted Byers <[EMAIL PROTECTED]>
> Date: Sat, 3 Nov 2007 21:32:43 -0400 (EDT)
> 
> > On a different note, I wish I had your budget for
> > hardware.  :-)
> 
> What budget?
> 
> These systems sit right at here with me at home, and
> I got all of them
> for free.
> 
How did you manage to get such machines for free?

Ted

Re: Results of 7z-4.55 performance with current GCCs.

[Joe Buck]

On Sun, Nov 04, 2007 at 01:32:16AM -0400, Ted Byers wrote:
> --- David Miller <[EMAIL PROTECTED]> wrote:
> > From: Ted Byers <[EMAIL PROTECTED]>
> > Date: Sat, 3 Nov 2007 21:32:43 -0400 (EDT)
> > 
> > > On a different note, I wish I had your budget for
> > > hardware.  :-)
> > 
> > What budget?
> > 
> > These systems sit right at here with me at home, and
> > I got all of them
> > for free.
> > 
> How did you manage to get such machines for free?

By being David Miller, or rather, by doing what David Miller does
(e.g. primary maintainer of Linux's networking stack as well as the Sparc
port of Linux, and a maintainer of Sparc port of gcc, in addition to many
other contributions to free software).

Re: Results of 7z-4.55 performance with current GCCs.

[David Miller]

From: Ted Byers <[EMAIL PROTECTED]>
Date: Sun, 4 Nov 2007 01:32:16 -0400 (EDT)

> --- David Miller <[EMAIL PROTECTED]> wrote:
> > From: Ted Byers <[EMAIL PROTECTED]>
> > Date: Sat, 3 Nov 2007 21:32:43 -0400 (EDT)
> > 
> > > On a different note, I wish I had your budget for
> > > hardware.  :-)
> > 
> > What budget?
> > 
> > These systems sit right at here with me at home, and
> > I got all of them
> > for free.
>
> How did you manage to get such machines for free?

Well if you put 2 and 2 together, you'd check and notice that I
maintain the sparc64 port of Linux.  As a result you might imagine
that I have acquired quite a number of Niagara systems.