Re: [rtl-optimization] Improve Data Prefetch for IA-64

[Steven Bosscher]

On Sunday 27 March 2005 04:45, Canqun Yang wrote:
> Another question is why the new RTL loop-unroller does
> not support giv splitting.

Apparently because for most people it is not a problem that it does
not do it, and while you have indicated earlier that it may be useful
for you, you have neither tried to implement it yourself, nor provided
a test case to PR20376.

FWIW you could try -fweb and see if it does what you want.  And if it
does, you could write a limited webizer patch that works on just loop
bodies after unrolling.

Gr.
Steven

Bootstrap error on powerpc-apple-darwin: stfiwx

[Geert Bosch]

%cat LAST_UPDATED
Sat Mar 26 21:31:28 EST 2005
Sun Mar 27 02:31:28 UTC 2005
stage1/xgcc -Bstage1/ -B/opt/gcc-head//powerpc-apple-darwin7.8.0/bin/ 
-c   -g -O2 -mdynamic-no-pic -DIN_GCC   -W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long 
-Wno-variadic-macros -Wold-style-definition -Werror-DHAVE_CONFIG_H  
  -I. -I. -I/Users/bosch/gcc/gcc -I/Users/bosch/gcc/gcc/. 
-I/Users/bosch/gcc/gcc/../include -I./../intl 
-I/Users/bosch/gcc/gcc/../libcpp/include -I/opt/include -I/opt/include 
/Users/bosch/gcc/gcc/c-cppbuiltin.c -o c-cppbuiltin.o
/var/tmp//ccsCOTn9.s:874:stfiwx instruction is optional for the PowerPC 
(not allowed without -force_cpusubtype_ALL option)
/var/tmp//ccsCOTn9.s:924:stfiwx instruction is optional for the PowerPC 
(not allowed without -force_cpusubtype_ALL option)
/var/tmp//ccsCOTn9.s:970:stfiwx instruction is optional for the PowerPC 
(not allowed without -force_cpusubtype_ALL option)
/var/tmp//ccsCOTn9.s:997:stfiwx instruction is optional for the PowerPC 
(not allowed without -force_cpusubtype_ALL option)
make[2]: *** [c-cppbuiltin.o] Error 1
make[1]: *** [stage2_build] Error 2
make: *** [bootstrap] Error 2

Likely offending patch:
2005-03-25  Geoffrey Keating  <[EMAIL PROTECTED]>
* config/rs6000/darwin-fallback.c: Don't include .
Use our own structure definitions.
* config/rs6000/rs6000.md (UNSPEC constants): Add UNSPEC_STFIWX.
(fix_truncdfsi2): Allow registers or memory as destination.
When TARGET_PPC_GFXOPT, generate simplified pattern.
(fix_truncdfsi2_internal): Use define_insn_and_split.
(fix_truncdfsi2_internal_gfxopt): New.
(fctiwz): Don't confuse register allocation by giving it no 
choices.
(stfiwx): New.
* config/rs6000/rs6000.h (EXTRA_CONSTRAINT): Add 'Z'.
(EXTRA_MEMORY_CONSTRAINT): Likewise.
* config/rs6000/rs6000.c (indexed_or_indirect_operand): New.
* config/rs6000/rs6000-protos.h (indexed_or_indirect_operand): 
New.

Re: Bootstrap error on powerpc-apple-darwin: stfiwx

[Andreas Tobler]

Geert Bosch wrote:
%cat LAST_UPDATED
Sat Mar 26 21:31:28 EST 2005
Sun Mar 27 02:31:28 UTC 2005
stage1/xgcc -Bstage1/ -B/opt/gcc-head//powerpc-apple-darwin7.8.0/bin/ 
-c   -g -O2 -mdynamic-no-pic -DIN_GCC   -W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long 
-Wno-variadic-macros -Wold-style-definition -Werror-DHAVE_CONFIG_H  
  -I. -I. -I/Users/bosch/gcc/gcc -I/Users/bosch/gcc/gcc/. 
-I/Users/bosch/gcc/gcc/../include -I./../intl 
-I/Users/bosch/gcc/gcc/../libcpp/include -I/opt/include -I/opt/include 
/Users/bosch/gcc/gcc/c-cppbuiltin.c -o c-cppbuiltin.o
/var/tmp//ccsCOTn9.s:874:stfiwx instruction is optional for the PowerPC 
(not allowed without -force_cpusubtype_ALL option)
/var/tmp//ccsCOTn9.s:924:stfiwx instruction is optional for the PowerPC 
(not allowed without -force_cpusubtype_ALL option)
/var/tmp//ccsCOTn9.s:970:stfiwx instruction is optional for the PowerPC 
(not allowed without -force_cpusubtype_ALL option)
/var/tmp//ccsCOTn9.s:997:stfiwx instruction is optional for the PowerPC 
(not allowed without -force_cpusubtype_ALL option)
make[2]: *** [c-cppbuiltin.o] Error 1
make[1]: *** [stage2_build] Error 2
make: *** [bootstrap] Error 2
http://gcc.gnu.org/ml/gcc/2005-03/msg01149.html
Gruss,
Andreas

Re: A plan for eliminating cc0

[Ian Lance Taylor]

Paul Schlie <[EMAIL PROTECTED]> writes:

>   I presume that "code" can/should be optimally generated once by initially
>   optimally covering the rtl representing a basic block (with minimal cost
>   in either storage, cycles or some hybrid of both); where there's then no
>   need to ever subsequently screw with it again (although various basic
>   block partitioning resulting from various loop transformations strategies,
>   etc. may require multiple mappings to determine their relative costs).
>   
>   Where this presumption basically ideally requires that the target be
>   described as accurately as possible entirely in rtl, with no reliance
>   on procedural or peephole optimization, relying entirely on GCC to
>   optimally cover the program's basic-block rtl optimally with rtl
>   instruction description equivalents; thereby by fully exposing all
>   dependencies, an optimal instruction schedule will naturally result
>   from an optimal rtl graph covering without needing to perform an
>   explicit further optimization for example.
>  
>   (is this not feasible if the target is accurately described in rtl?)

I don't know how to respond to this.  I'm discussing a way to achieve
an incremental improvement in gcc.  You seem to be discussing a
different compiler.  I don't think my suggestions for incremental
improvement are relevant to creating your compiler: they don't help,
and they don't hurt.

Perhaps somebody else has something to say about this, but I don't.
I'm a practical guy: I compile code with the compiler I have, not the
compiler I might want or wish to have.

Ian

Gcc embedding issue of our commerical product

[anderson shin]

Dear GNU,

Hello? I'm Anderson Shin([EMAIL PROTECTED]), director of
IPEAN(ipean.com) company in South Korea.

To begin with, please let me introduce shortly about our company. 

We are developping EDA(Electronic Design Automation) tools that is CAD
system for digital/analog IC/circuit designing.

Our product name is Flowrian that is the IDE environment like MinGW or
Visual Studio and it will be released soon(We are going to attend the
DAC conference(dac.com) at California in June and our product will be
released in August).

And now, the Flowrian application can be interlinked with other C++
compiler tools, and the GCC is one of it, too.

By the way, we think that the GCC is the best C++ compiler among all
the others, and so we want to include the GCC crudely to our new
product with GNU license.

But, our product is commerical one, so we are sorry that we would not
open the source code of our product.

A purpose of including the GCC to our product is only for our
customer's convenience, because if it couldn't be, then our customers
have to download the GCC directly as themselves.

But, if we can include the GCC to our product, it means, all of our
customers have to use the GCC first, so we think that is good to GNU,
too.

However we always respect an opinion of the GNU. So we will follow
your decision and we hope our suggestion will be accepted.

Thank you for reading all. I hope the GNU grow much up day by day more. 

Best Regards

Anderson Shin

gcc build is broken on powerpc-apple-darwin

[Mostafa Hagog]

I guess its due to the following patch (
http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01320.html).
I get the following error when trying to build gcc on powerpc-apple-darwin:
gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../../gcc/libiberty/../include  -W
-Wall -Wtraditional -pedantic ../../../gcc/libiberty/getopt1.c -o getopt1.o
../../../gcc/libiberty/getopt1.c: In function `getopt_long':
../../../gcc/libiberty/getopt1.c:71: warning: traditional C rejects ISO C
style function definitions
../../../gcc/libiberty/getopt1.c: At top level:
../../../gcc/libiberty/getopt1.c:83: error: conflicting types for
'getopt_long_only'
../../../gcc/libiberty/../include/getopt.h:125: error: previous declaration
of 'getopt_long_only' was here
../../../gcc/libiberty/getopt1.c: In function `getopt_long_only':
../../../gcc/libiberty/getopt1.c:83: warning: traditional C rejects ISO C
style function definitions
../../../gcc/libiberty/getopt1.c:84: warning: passing arg 3 of
`_getopt_internal' from incompatible pointer type
make[1]: *** [getopt1.o] Error 1
make: *** [all-build-libiberty] Error 2

Mostafa.

Re: A plan for eliminating cc0

[Paul Schlie]

> From: Ian Lance Taylor 
>> Paul Schlie <[EMAIL PROTECTED]>
>>   (is this not feasible if the target is accurately described in rtl?)
> 
> I don't know how to respond to this.  I'm discussing a way to achieve
> an incremental improvement in gcc.  You seem to be discussing a
> different compiler.  I don't think my suggestions for incremental
> improvement are relevant to creating your compiler: they don't help,
> and they don't hurt.
> 
> Perhaps somebody else has something to say about this, but I don't.
> I'm a practical guy: I compile code with the compiler I have, not the
> compiler I might want or wish to have.

- sorry, there's no need to respond; I need to concentrate on reality too.

Re: gcc build is broken on powerpc-apple-darwin

[Gabriel Dos Reis]

Mostafa Hagog <[EMAIL PROTECTED]> writes:

| I guess its due to the following patch (
| http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01320.html).
| I get the following error when trying to build gcc on powerpc-apple-darwin:
| gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../../gcc/libiberty/../include  -W
| -Wall -Wtraditional -pedantic ../../../gcc/libiberty/getopt1.c -o getopt1.o
| ../../../gcc/libiberty/getopt1.c: In function `getopt_long':
| ../../../gcc/libiberty/getopt1.c:71: warning: traditional C rejects ISO C
| style function definitions
| ../../../gcc/libiberty/getopt1.c: At top level:
| ../../../gcc/libiberty/getopt1.c:83: error: conflicting types for
| 'getopt_long_only'
| ../../../gcc/libiberty/../include/getopt.h:125: error: previous declaration
| of 'getopt_long_only' was here
| ../../../gcc/libiberty/getopt1.c: In function `getopt_long_only':
| ../../../gcc/libiberty/getopt1.c:83: warning: traditional C rejects ISO C
| style function definitions
| ../../../gcc/libiberty/getopt1.c:84: warning: passing arg 3 of
| `_getopt_internal' from incompatible pointer type
| make[1]: *** [getopt1.o] Error 1
| make: *** [all-build-libiberty] Error 2

Fixed with this

   http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02450.html

Please try again and let me know.  

-- Gaby

Re: [rtl-optimization] Improve Data Prefetch for IA-64

[Zdenek Dvorak]

Hello,

> On Sunday 27 March 2005 03:53, Canqun Yang wrote:
> > The last ChangeLog of rtlopt-branch was written in
> > 2003. After more than one year, many impovements in
> > this branch haven't been put into the GCC HEAD. Why?
> 
> Almost all of the rtlopt branch was merged.  Prefetching is one
> of the few things that was not, probably Zdenek knows why.

because I never made it work as well as the current version,
basically.  At least no matter how much I tried, I never produced
any benchmark numbers that would justify the change.  Then I went
to tree-ssa (and tried to write prefetching there, and got stuck on
the same issue, after which I simply forgot due to loads of other work
:-( ).

Zdenek

gcc-4.1-20050327 is now available

[gccadmin]

Snapshot gcc-4.1-20050327 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050327/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.1 CVS branch
with the following options:  -D2005-03-27 17:43 UTC

You'll find:

gcc-4.1-20050327.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20050327.tar.bz2 C front end and core compiler

gcc-ada-4.1-20050327.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20050327.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20050327.tar.bz2  C++ front end and runtime

gcc-java-4.1-20050327.tar.bz2 Java front end and runtime

gcc-objc-4.1-20050327.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20050327.tar.bz2The GCC testsuite

Diffs from 4.1-20050320 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: [rtl-optimization] Improve Data Prefetch for IA-64

[Zdenek Dvorak]

Hello,

> On Sunday 27 March 2005 04:45, Canqun Yang wrote:
> > Another question is why the new RTL loop-unroller does
> > not support giv splitting.
> 
> Apparently because for most people it is not a problem that it does
> not do it, and while you have indicated earlier that it may be useful
> for you, you have neither tried to implement it yourself, nor provided
> a test case to PR20376.
> 
> FWIW you could try -fweb and see if it does what you want.  And if it
> does, you could write a limited webizer patch that works on just loop
> bodies after unrolling.

from what I understood, change to analyze_iv_to_split_insn that would
detect memory references should suffice.  Also maybe this patch might be
relevant:

http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01176.html

Zdenek

dejagnu help needed - tests get confused by column numbers

[Per Bothner]

If you run 'make check' after --enable-mapped-location (even
just --enable-languages=c) you'll find some apparant regressions.
They aren't real regressions - it's just now we now get column numbers
in some of the diagnostic messages, and this confuses dejagnu.
Now I'm willing to fix those tests by adding -fno-show-column where
necessary, and this fixes those testcases.  However, that obviously
is a kludge.  The Right Thing to do is to fix dejagnu so it doesn't get
confused by column numbers.  I'm guessing this is a one- or two-line
fix, but I don't know dejagnu, I've forgotten most of what little I
used to know about tcl, and I don't know where to start.  I'm asking
for someone who will know the Right Thing, and who will do.
Anyone out there?
--
--Per Bothner
[EMAIL PROTECTED]   http://per.bothner.com/

Re: Gcc embedding issue of our commerical product

[Mike Stump]

On Sunday, March 27, 2005, at 08:55  AM, anderson shin wrote:
However we always respect an opinion of the GNU. So we will follow
your decision and we hope our suggestion will be accepted.
Mostly, this is off-topic for this list.  gnu.misc.discuss is the 
canonical place for such discussions.  I'll send you a more direct 
answer off list.

Re: dejagnu help needed - tests get confused by column numbers

[Mike Stump]

On Sunday, March 27, 2005, at 11:58  AM, Per Bothner wrote:
If you run 'make check' after --enable-mapped-location (even
just --enable-languages=c) you'll find some apparant regressions.
They aren't real regressions - it's just now we now get column numbers
in some of the diagnostic messages, and this confuses dejagnu.
Now I'm willing to fix those tests by adding -fno-show-column where
necessary, and this fixes those testcases.  However, that obviously
is a kludge.  The Right Thing to do is to fix dejagnu so it doesn't get
confused by column numbers.  I'm guessing this is a one- or two-line
fix, but I don't know dejagnu, I've forgotten most of what little I
used to know about tcl, and I don't know where to start.  I'm asking
for someone who will know the Right Thing, and who will do.
Anyone out there?
See dejagnu, lib/dg.exp:
# Line number format.  This is how line numbers appear in program 
output.
set dg-linenum-format ":%d:"

and all the consumers of this...
You might be able to do something line:
set dg-linenum-format "\[-0-9\]:%d:"
or
set dg-linenum-format ":%d:\[-0-9\]+:"
and get kinda close.  Of course, this may be repeated in multiple 
places.  The second form would only be if error messages were 
unconditionally in column number form.

Another approach would be to canonicalize the output just before set 
comp_output [lindex $results 0], and s/:\([0-9]+\):[0-9]+:/:\1:' it to 
remove the column number.  To do this, you can experiment with tclsh 
and regsub in the small, until it works, and then plug it in and try it.

Re: dejagnu help needed - tests get confused by column numbers

[Mike Stump]

On Sunday, March 27, 2005, at 11:58  AM, Per Bothner wrote:
Now I'm willing to fix those tests by adding -fno-show-column where
necessary
Ick.  I favor adding it unconditionally to compile lines over this.  
See -fmessage-length code (gcc/testsuite/lib/g++.exp) for hints.  And 
even that, I'm not sure I favor.  For the short term, we can add it, as 
otherwise I suspect we'd create a requirement of a new dejagnu release 
and to use it, which I favor even less.  dejagnu should also be 
enhanced to handle column numbers, even if we put in code to add the 
option.

Re: gcc build is broken on powerpc-apple-darwin

[Mike Stump]

On Sunday, March 27, 2005, at 09:31  AM, Gabriel Dos Reis wrote:
Fixed with this
   http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02450.html
Please try again and let me know.
A quick check of build's libiberty, seems to build for me now on 
darwin8.

Re: gcc build is broken on powerpc-apple-darwin

[Gabriel Dos Reis]

Mike Stump <[EMAIL PROTECTED]> writes:

| On Sunday, March 27, 2005, at 09:31  AM, Gabriel Dos Reis wrote:
| > Fixed with this
| >
| >http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02450.html
| >
| > Please try again and let me know.
| 
| A quick check of build's libiberty, seems to build for me now on
| darwin8.

Thanks!

-- Gaby

Re: Bootstrap error on powerpc-apple-darwin: stfiwx

[Geoff Keating]

On 27/03/2005, at 4:00 AM, Geert Bosch wrote:
%cat LAST_UPDATED
Sat Mar 26 21:31:28 EST 2005
Sun Mar 27 02:31:28 UTC 2005
stage1/xgcc -Bstage1/ -B/opt/gcc-head//powerpc-apple-darwin7.8.0/bin/ 
-c   -g -O2 -mdynamic-no-pic -DIN_GCC   -W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long 
-Wno-variadic-macros -Wold-style-definition -Werror-DHAVE_CONFIG_H 
   -I. -I. -I/Users/bosch/gcc/gcc -I/Users/bosch/gcc/gcc/. 
-I/Users/bosch/gcc/gcc/../include -I./../intl 
-I/Users/bosch/gcc/gcc/../libcpp/include -I/opt/include -I/opt/include 
/Users/bosch/gcc/gcc/c-cppbuiltin.c -o c-cppbuiltin.o
/var/tmp//ccsCOTn9.s:874:stfiwx instruction is optional for the 
PowerPC (not allowed without -force_cpusubtype_ALL option)
/var/tmp//ccsCOTn9.s:924:stfiwx instruction is optional for the 
PowerPC (not allowed without -force_cpusubtype_ALL option)
/var/tmp//ccsCOTn9.s:970:stfiwx instruction is optional for the 
PowerPC (not allowed without -force_cpusubtype_ALL option)
/var/tmp//ccsCOTn9.s:997:stfiwx instruction is optional for the 
PowerPC (not allowed without -force_cpusubtype_ALL option)
make[2]: *** [c-cppbuiltin.o] Error 1
make[1]: *** [stage2_build] Error 2
make: *** [bootstrap] Error 2
You need to upgrade your cctools, see 
.

smime.p7s
Description: S/MIME cryptographic signature

Re: [rtl-optimization] Improve Data Prefetch for IA-64

[Canqun Yang]

ÒýÑÔ Zdenek Dvorak <[EMAIL PROTECTED]>:

> Hello,
>
> > On Sunday 27 March 2005 03:53, Canqun Yang wrote:
> > > The last ChangeLog of rtlopt-branch was written 
in
> > > 2003. After more than one year, many impovements 
in
> > > this branch haven't been put into the GCC HEAD. 
Why?
> >
> > Almost all of the rtlopt branch was merged.  
Prefetching is one
> > of the few things that was not, probably Zdenek 
knows why.
>
> because I never made it work as well as the current 
version,
> basically.  At least no matter how much I tried, I 
never produced
> any benchmark numbers that would justify the 
change.  Then I went
> to tree-ssa (and tried to write prefetching there, 
and got stuck on
> the same issue, after which I simply forgot due to 
loads of other work
> :-( ).
>
> Zdenek
> 

It shoud be the similar reason as comments in my 
previously supplied patch. 

http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02400.html
.

Canqun Yang
Creative Compiler Research Group.
National University of Defense Technology, China.

Re: [rtl-optimization] Improve Data Prefetch for IA-64

[Canqun Yang]

ÒýÑÔ Zdenek Dvorak <[EMAIL PROTECTED]>:

> Hello,
>
> > On Sunday 27 March 2005 04:45, Canqun Yang wrote:
> > > Another question is why the new RTL loop-
unroller does
> > > not support giv splitting.
> >
> > Apparently because for most people it is not a
problem that it does
> > not do it, and while you have indicated earlier
that it may be useful
> > for you, you have neither tried to implement it
yourself, nor provided
> > a test case to PR20376.
> >
> > FWIW you could try -fweb and see if it does what
you want.  And if it
> > does, you could write a limited webizer patch that
works on just loop
> > bodies after unrolling.
>
> from what I understood, change to
analyze_iv_to_split_insn that would
> detect memory references should suffice.  Also maybe
this patch might be
> relevant:
>
> http://gcc.gnu.org/ml/gcc-patches/2004-
10/msg01176.html
>
> Zdenek
>

I'll try this. Thanks a lot.


Canqun Yang
Creative Compiler Research Group.
National University of Defense Technology, China.

Re: Merging CCP and VRP?

[Kazu Hirata]

Hi Diego,

> By merging, do you mean *replacing* CCP with VRP?  Yes, it's
> doable.  No, it's not a good idea.

Understood.

Also, if we are inserting ASSERT_EXPRs, it seems to be a good idea to
run copy-prop before VRP.  Otherwise, we would end up with lots of

  D.18001_101 = D.18001_198;
  D.18011_102 = D.18001_101->head_;
  D.18001_12 = ASSERT_EXPR ;

Note that ASSERT_EXPR is on D.18001_101, not on D.18001_198, which is
older.  As a result, VRP does not notice that D.18001_198 != 0B.
Currently, we still have these even after copy prop because we don't
allow copy propagation between const and non-const pointers, which I
think is a bit too restrictive.

> At one point, all the passes had to deal with ASSERT_EXPRs.
> Mostly by ignoring them.  Which is additional, unwanted work
> because some of them had to actively know about them being
> nothing but fancy copy operations.  That gets in the way of their
> work.  I think that ASSERT_EXPRs should only survive as long as
> they're useful.

Yes, playing with VRP, I've realized that I am not interested in
ASSERT_EXPRs per se, but I am more interested in SSA_NAME_VALUE_RANGE
that VRP leaves us with.

> Sure.  Go ahead.  My short term plan is to start merging the various
> components into mainline.  I'll start with the incremental SSA
> patches, followed by VRP, the CCP and copy-prop improvements.
> Perhaps we could leave the changes to the threader in TCB for a
> little while longer, but first I need to read your proposal in
> detail.

Thank you.  It turns out that if I blindly insert ASSERT_EXPRs for
everything that allows us to infer a range, my jump threading pass
finds more opportunities than what the current DOM can find.  There
are certain classes of opportunities that my pass misses but DOM
catches, but I'll mention them in a separate message.

> ISTR either stevenb or dberlin implementing a dom-order
> propagation.  I think they got a minor speedup that could be
> worth having.

Huh, whey I talked to them on IRC they didn't seem to have implemented
this.  I'll try to get this issue one of these days.

Kazu Hirata

Re: ISO C prototype style for libiberty?

[DJ Delorie]

> Isn't that what newlib is for...?

"Should be" does not mean "is".  I know libiberty has been used for
this purpose in the past (remember the demangler in libstdc++ times?)
so I wouldn't want to assume we aren't still doing it.

> I should be clear, though; I only want to make this assumption for
> the host and build systems.

That's hard for libiberty, where it is also used for target systems.

Re: Merging CCP and VRP?

[Diego Novillo]

On Sun, Mar 27, 2005 at 08:08:43PM -0500, Kazu Hirata wrote:

> Also, if we are inserting ASSERT_EXPRs, it seems to be a good idea to
> run copy-prop before VRP.  Otherwise, we would end up with lots of
> 
There is a copy-propagation pass before VRP.  Or do you mean
right before?  Sure, the ordering of these passes is in eternal
flux anyway.

> Currently, we still have these even after copy prop because we don't
> allow copy propagation between const and non-const pointers, which I
> think is a bit too restrictive.
> 
I assume these are blocked by may_propagate_copy.  What's
blocking these?  Do they have different alias set numbers or do
we need a conversion from the const to the non-const version?

> > ISTR either stevenb or dberlin implementing a dom-order
> > propagation.  I think they got a minor speedup that could be
> > worth having.
> 
> Huh, whey I talked to them on IRC they didn't seem to have implemented
> this.  I'll try to get this issue one of these days.
> 
Maybe I'm thinking of someone else.  I do remember somebody
playing with this.  Oh, well, it doesn't matter.  It's easy
enough to change at anytime.


Diego.

Re: Merging CCP and VRP?

[Kazu Hirata]

Hi Diego,

> There is a copy-propagation pass before VRP.  Or do you mean
> right before?  Sure, the ordering of these passes is in eternal
> flux anyway.

"Before", but doesn't have to be "right before".  The current ordering
is reasonable.

> > Currently, we still have these even after copy prop because we don't
> > allow copy propagation between const and non-const pointers, which I
> > think is a bit too restrictive.
> > 
> I assume these are blocked by may_propagate_copy.  What's
> blocking these?  Do they have different alias set numbers or do
> we need a conversion from the const to the non-const version?

Yes, they are blocked by may_propagate_copy.  Seems to be const
v.s. non-const pointer issue.  I haven't come up with a brakedown of
reasons why copies are blocked.

Kazu Hirata

Re: A plan for eliminating cc0

[Paul Schlie]

Hi Ian, (getting back to reality) upon reviewing things further, it appears
that if GCC could relax it's single-set restriction to enable a restricted
form of multi-set instructions to be included in optimizations; then ISA's
who's instructions either implicitly set or depend on global machine state
which directly correspond to that instruction's single result value, would
be enabled to be both accurately modeled and fully safely optimized.

More specifically, if GCC enabled set to optionally specify multiple targets
for a single rtl source expression, i.e.:

  (set ((reg:xx %0) (reg CC) ...) (some-expression:xx ...))

Then it would seem that this single common rtl source expression may be
optimized as if it were a single-set expression with the only restriction
that instructions with multiple active sets may only be merged with it's
source operand instructions when all of it's live sets may correspondingly
be represented in the newly merged instruction, i.e.:

(add %0 %1); (set ((reg %0) (reg CC)) (add (reg %0) (reg %1))
   ; %0 live, CC dead
(sub %0 1) ; (set ((reg %0) (reg CC)) (sub (reg %0) (int  1))
   ; %0 live, CC live
=> 
(add-1 a b); (set ((reg %0) (reg CC)) (sub (add (reg %0) (reg %1)) (int 1)))
   ; %0 live, CC live

Thereby enabling clean fully exposed global-cc-status target descriptions:

(insn  (set ((reg %0) (reg CC)) ( (reg: %0) (reg: %1)))
   ...)

(insn brne (set (PC) (if_then_else
   (ne: 0 (reg CC))
   (label_ref %0)
   (PC
   ...)

Might this likely work?  And if so, possibly be worthy of consideration to
enable the more efficient description and optimization of traditional cc0
target machines (and possibly be beneficial for other ISA's as well)?

about gcc-4.1-20050327

[zouq]

i build a crosscompiler for gcc, abi=n32
gcc-4.1-20050327/configure  -target=mips64el-linux
-prefix=/opt/gcc-4.1-20050327/ -enable-languages=c --disable-shared
make

it will error with config/mips/mips.c