Reload producing lots of duplicate insns

[Steven Bosscher]

Hi,

While teaching dce.c on the dataflow-branch to delete noop-moves,
I noticed that most noop moves are produced by reload.  It inserts
duplicate insns for some reloads, postreload turns the duplicate
reload into a simple reg-reg move (but the lhs and rhs are the same
register of course), and then dce.c removes these moves because
they are noop-moves.

Example:
Before reload we just have some variable, ivtmp.46, in a pseudo:
(insn 45 43 47 6 (set (reg:SI 62 [ D.1617 ])
(reg:SI 63 [ ivtmp.46 ])) 40 {*movsi_1} (nil)
(nil))

After reload we have this:
(insn 45 43 102 6 (set (reg:SI 4 si [orig:62 D.1617 ] [62])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -16 [0xfff0])) [0 ivtmp.46+0 S4 A8])) 40 
{*movsi_1} (nil)
(nil))

(insn 102 45 47 6 (set (reg:SI 4 si [orig:62 D.1617 ] [62])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -16 [0xfff0])) [0 ivtmp.46+0 S4 A8])) 40 
{*movsi_1} (nil)
(nil))

Note, that these insns are identical.
After postreload it looks like this:
(insn 45 43 102 6 (set (reg:SI 4 si [orig:62 D.1617 ] [62])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -16 [0xfff0])) [0 ivtmp.46+0 S4 A8])) 40 
{*movsi_1} (nil)
(nil))

(insn 102 45 47 6 (set (reg:SI 4 si [orig:62 D.1617 ] [62])
(reg:SI 4 si [orig:62 D.1617 ] [62])) 40 {*movsi_1} (nil)
(nil))

Then on the dataflow-branch, dce removes insn 102.  On mainline,
flow2 takes care of that.


Test case for ix86 is this:

/* This is reduced from count_reg_usage in cse.c.
   Compile with gcc -S -march=i686 -m32 -O -fno-tree-ch t.c -da
   and look at the .greg and .postreload RTL dumps.
   With "gcc (GCC) 4.2.0 20060225 (experimental)", look for insn 45
   and insn 102.  */

typedef struct rtvec_def
{
  unsigned num_elem;
  struct rtx_def *elem[1];
} *rtvec;

typedef struct rtx_def
{
  struct rtvec_def *rtvec[1];
} *rtx;

extern int rtx_length[];

void
foo (rtx x, const char c, int code)
{
  int i, j;

  for (i = (rtx_length[code]) - 1; i >= 0; i--)
{
  if (c == 'e')
asm volatile ("":::"0", "1", "2", "3", "4", "5");
  else if (c == 'E')
for (j = x->rtvec[i]->num_elem - 1; j >= 0; j--)
  foo (x->rtvec[i]->elem[j], c, code);
}
}


I don't understand reload at all.  Could someone help me figure out why
we have two identical insns there?  We produce hundreds of basically
dead insns like this, and we need post-reload passes to clean them up.
So if we can avoid emitting the second, redundant insn, that'd be a win.

Gr.
Steven

Re: Reload producing lots of duplicate insns

[Kenneth Zadeck]

Steven Bosscher wrote:
> Hi,
>
> While teaching dce.c on the dataflow-branch to delete noop-moves,
> I noticed that most noop moves are produced by reload.  It inserts
> duplicate insns for some reloads, postreload turns the duplicate
> reload into a simple reg-reg move (but the lhs and rhs are the same
> register of course), and then dce.c removes these moves because
> they are noop-moves.
>
>   
Steven,

Did richard's untested patch not fix this?


Kenny

Re: Reload producing lots of duplicate insns

[Steven Bosscher]

On Sunday 26 February 2006 14:23, Kenneth Zadeck wrote:
> Did richard's untested patch not fix this?

No.  That patch only makes postreload not emit those reg-reg moves,
but it does not prevent reload from producing the redundant insns in
the first place.  So that patch just papers over the problem we seem
to have in reload.

Gr.
Steven

Request to become moderator of crossgcc mailing list

[Dan Kegel]

The crossgcc mailing list really needs some moderator lovin'.
e.g. an address on the crossgcc mailing list is bouncing,
and needs removal.  Worse, the blurb at the bottom of each
post has needed updating for the last four years or so.

I seem to be one of the main players on that list these days,
and I'm willing.  Any chance I could become a
moderator of the crossgcc list?

Thanks,
Dan

--
Wine for Windows ISVs: http://kegel.com/wine/isv

Re: Request to become moderator of crossgcc mailing list

[Christopher Faylor]

[Note that reply-to is set to sourcemaster to prevent any further pollination
in the gcc mailing list]
On Sun, Feb 26, 2006 at 09:14:12AM -0800, Dan Kegel wrote:
>The crossgcc mailing list really needs some moderator lovin'.  e.g.  an
>address on the crossgcc mailing list is bouncing, and needs removal.

It would help if you mentioned what the address is.  FWIW, ezmlm is
supposed to detect bouncing email and remove addresses automatically.
However, if the mail is bouncing directly back to senders then the only
way we know to remove it is if someone sends the headers on to
postmaster.

>Worse, the blurb at the bottom of each post has needed updating for the
>last four years or so.

I've removed the (indirect) reference to Bill Gatliff's site.

>I seem to be one of the main players on that list these days, and I'm
>willing.  Any chance I could become a moderator of the crossgcc list?

I'd have to check with the other administrators of this site but, in the
meantime, please forward the bouncing email to postmaster so that we can
unsubscribe the person with the email problems.

Btw, I do follow the crossgcc list and correct any obvious problems.  I missed
the fact that the trailer referred to an obsolete web site, however.

cgf

Re: Tuples for GIMPLE

[Mark Mitchell]

Diego Novillo wrote:
> A few days ago we had chatted with Ian on IRC about the general idea of
> using some tuple-like structure for GIMPLE instead of the current notion
> of treating everything as a 'tree'.  We also chatted briefly with Zdenek
> about this when he proposed turning compiler temporaries into non-decls.
>  I think all these threads are converging and we should probably start
> doing something about it.

I've been thinking about this in the back of my mind as well.  I think
we're all agreed that everything-is-a-tree is not what we want, and that
this kind of "tree trimming" is a good idea.

> modify_expr =   4770176 ( 75%)
> label_expr  =860960 ( 13%)

Very nice.  That does tell us a lot.

My initial suggestion for a first angle of attack is:

1) Reorder tree_common so that the "code" and bitfields are first.

2) Redefine tree_common as:

struct tree_base {
  enum tree_code code:8;
  /* flags */
};
struct tree_common {
  struct tree_base base;
  tree chain;
  tree type;
  union tree_ann_d *ann;
};

3) Define a SSA_MODIFY_EXPR as follows:

struct tree_ssa_mod_expr {
  struct tree_base base;
  /* operands */
};

4) Adjust TREE_TYPE, TREE_CHAIN, etc. to fault when operating on an
SSA_MODIFY_EXPR.  (Or, have them return NULL_TREE.  Or, perhaps, you
want TREE_TYPE to return void_type_node or the type of the operands, for
convenience?)

5) Allocate SSA_MODIFY_EXPRs, not MODIFY_EXPRs, for SSA.  Fix all the
assertions. :-)

The reason I'd keep tree_base is that you presumably need some kind of
tag to tell you what you've got anyhow.  So, you're wasting at most one
word, rather than the current four, and you can still leverage some of
the existing machinery.

The more radical approach would just be to define a completely new
family of nodes for SSA form.  That would allow you to drop the
remaining word. I'm not sure how much harder that would be, if any; it
might be that the "radical" solution is no more work.  However, the
suggestion above means that you can convert MODIFY_EXPRs without
converting the other things pointed to by a SSA statement, since they
are still trees, at least to the point of having a tree_code.  Then,
once everything had an SSA_ form, the conversion to
not-trees-at-all would be easy.  The other nice thing about the less
radical approach is that it might let us start incoporating the leaner
trees into the rest of our IL; we'd start having the idea of
trees-without-a-TREE_CHAIN.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: [PATCH, RFC] Enable IBM long double for PPC32 Linux

[Gerald Pfeifer]

On Mon, 6 Feb 2006, David Edelsohn wrote:
>Andrew> Your attitude towards Joern's request for help with a regression was 
>really
>Andrew> what got my over the board.  Your suggestion that a primary target was 
>more
>Andrew> important even for an enhancement matter than over a regression was 
>really
>Andrew> out of line.
>   I am sorry that you took personal offsense at my comment.  My
> comments reflected my understanding of the GCC 4.1 release criteria and
> the GCC Mission Statement.

For the record, I reviewed both the Mission Statement and the GCC 4.1 
release criteria.  Neither is really applicable.

The most applicable parts of our policies can be found in the GCC
Development Plan at  and 
.


Mark, as the release manager, agreed to make an exception for ppc and
long double, and the case per se is bridge under the water.  Nevertheless,
it is important to correctly represent our policies.

Gerald

Re: [PATCH, RFC] Enable IBM long double for PPC32 Linux

[David Edelsohn]

> Gerald Pfeifer writes:

Gerald> For the record, I reviewed both the Mission Statement and the GCC 4.1 
Gerald> release criteria.  Neither is really applicable.

My comment said "my understanding".  You interpret them
differently.  Neither of us is representing the entire GCC SC in either
statement.

David

Re: [PATCH, RFC] Enable IBM long double for PPC32 Linux

[Andrew Pinski]

On Feb 26, 2006, at 4:40 PM, David Edelsohn wrote:


Gerald Pfeifer writes:


Gerald> For the record, I reviewed both the Mission Statement and the 
GCC 4.1

Gerald> release criteria.  Neither is really applicable.

My comment said "my understanding".  You interpret them
differently.  Neither of us is representing the entire GCC SC in either
statement.


It is over and done with and does not matter with any more really.
Any more talk about this would look rather unproductive at this time.

-- Pinski

Re: GCC-4.1.x include/ssl/*.h ??

[Gerald Pfeifer]

On Sun, 26 Feb 2006, Ralf Corsepius wrote:
> Cross building and installing gcc-4.1.0 rc2 (--prefix=/usr/local)
> installs these headers:
> 
> /usr/local/include/ssp/unistd.h
> /usr/local/include/ssp/string.h
> /usr/local/include/ssp/ssp.h
> /usr/local/include/ssp/stdio.h
> 
> Is this behavior correct?
> 
> /usr/local/include is reserved for host files. These files (Seemingly
> new in GCC-4.1.x) are the only host files GCC is installing when
> building a cross-compiler.

Indeed, this is a bug.

And it's a bug both for for cross-compilation as well as native 
compilation


Related problems include Bugzilla #23935 ($PREFIX/include/ffi.h),
#25938 ($PREFIX/include/gomp.h), and #18244 (include/mf-runtime.h).

Frank, any chance you could look into the mudflup one?

Unfortunately, we don't have a libffi maintainer listed. :-(

Gerald

Re: [gnu.org #225214] apparent mistake in html attribute

[Gerald Pfeifer]

On Fri, 24 Feb 2006, John Sullivan via RT wrote:
> I'm doing some housecleaning, and thought I should pass on this rather
> old message to you that we received in the GNU Webmasters queue about
> the sidebar on your web pages.
> 
> Can someone acknowledge this? Thanks!

Acknowledged.  I installed the patch below to our "stylesheet" which
replaces the 1% by 10em and refreshed all web pages on gcc.gnu.org;
http://www.gnu.org/software/gcc/ should be updated within 24 hours.

This is not what the user had suggested, but I believe it's the more 
appropriate fix.  Tested with current versions of lynx, links, w3m,
konqueror, and Mozilla.

Gerald

Index: style.mhtml
===
RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v
retrieving revision 1.84
diff -u -3 -p -r1.84 style.mhtml
--- style.mhtml 28 Oct 2005 20:11:29 -  1.84
+++ style.mhtml 26 Feb 2006 23:15:05 -
@@ -126,7 +126,7 @@
   
 
  
-  
+  
 
"java/[^/]*.html">

Re: GCC-4.1.x include/ssl/*.h ??

[Frank Ch. Eigler]

Hi -

On Sun, Feb 26, 2006 at 10:54:09PM +0100, Gerald Pfeifer wrote:
> On Sun, 26 Feb 2006, Ralf Corsepius wrote:
> > Cross building and installing gcc-4.1.0 rc2 (--prefix=/usr/local)
> > installs these headers:
> > [...]
> Related problems include Bugzilla #23935 ($PREFIX/include/ffi.h),
> #25938 ($PREFIX/include/gomp.h), and #18244 (include/mf-runtime.h).
> Frank, any chance you could look into the mudflup one?

I'm not fresh on gcc configury details.  If anyone can send a pointer
to the relevant autoconf or derived value, that would be great.

- FChE

can't create crtbegin.o: Invalid bfd target

[Eric Fisher]

Hello,
My port is originally aimed for mytarget-elf and has been able to built to use.
Now I want to use another target, mytarget-linux, just like mips-elf
and mips-linux.
Binutils is ok and has been installed, but when build gcc, there is
such a error,

/home/smj/build_gcc_linux/gcc/xgcc -B/home/smj/build_gcc_linux/gcc/ -B/home/smj/
local//mytarget-linux/bin/ -B/home/smj/local//mytarget-linux/lib/
-isystem /home/smj/local
//mytarget-linux/include -isystem
/home/smj/local//mytarget-linux/sys-include -O2 -DIN_GCC
 -DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-protot
ypes -Wold-style-definition  -isystem ./include  -I. -I.
-I../../gcc-3.4.4-mytarget/g
cc -I../../gcc-3.4.4-mytarget/gcc/.
-I../../gcc-3.4.4-mytarget/gcc/../include   -g0 -finhi
bit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-i
n-bss -fno-unit-at-a-time  \
  -Dinhibit_libc -c ../../gcc-3.4.4-mytarget/gcc/crtstuff.c -DCRT_BEGIN \
  -o crtbegin.o
In file included from ./tm.h:9,
 from ../../gcc-3.4.4-mytarget/gcc/crtstuff.c:64:
../../gcc-3.4.4-mytarget/gcc/config/mytarget/mytarget.h:1824:1:
warning: multi-line comment
../../gcc-3.4.4-mytarget/gcc/config/mytarget/mytarget.h:1833:1:
warning: multi-line comment
Assembler messages:
FATAL: can't create crtbegin.o: Invalid bfd target
make[1]: *** [crtbegin.o] Error 1

Are there anyone can give me some suggestion? The configuration of gcc is,
../gcc-3.4.4-mytarget/configure --target=mytarget-lin
ux --prefix=/home/smj/local/
--with-as=/home/smj/local/bin/mytarget-linux-as --with-
ld=/home/smj/local/bin/mytarget-linux-ld

Kind regards,
Eric.

Re: GCC-4.1.x include/ssl/*.h ??

[Ralf Corsepius]

On Sun, 2006-02-26 at 18:29 -0500, Frank Ch. Eigler wrote:
> Hi -
> 
> On Sun, Feb 26, 2006 at 10:54:09PM +0100, Gerald Pfeifer wrote:
> > On Sun, 26 Feb 2006, Ralf Corsepius wrote:
> > > Cross building and installing gcc-4.1.0 rc2 (--prefix=/usr/local)
> > > installs these headers:
> > > [...]
> > Related problems include Bugzilla #23935 ($PREFIX/include/ffi.h),
> > #25938 ($PREFIX/include/gomp.h), and #18244 (include/mf-runtime.h).
> > Frank, any chance you could look into the mudflup one?
> 
> I'm not fresh on gcc configury details.  If anyone can send a pointer
> to the relevant autoconf or derived value, that would be great.

/me thinks this isn't a bug inside of the Makefile.am, but either
- a bug in toplevel configure script, which gets exposed in all the
library subpackages, mentioned above (you would have to call these
subpackages' configure with an explicit --includedir=

Re: can't create crtbegin.o: Invalid bfd target

[Daniel Jacobowitz]

On Mon, Feb 27, 2006 at 10:20:43AM +0800, Eric Fisher wrote:
> Are there anyone can give me some suggestion? The configuration of gcc is,
> ../gcc-3.4.4-mytarget/configure --target=mytarget-lin
> ux --prefix=/home/smj/local/
> --with-as=/home/smj/local/bin/mytarget-linux-as --with-
> ld=/home/smj/local/bin/mytarget-linux-ld

Then this is the wrong list; your binutils port is broken.

-- 
Daniel Jacobowitz
CodeSourcery

intermediate representation

[Mateusz Berezecki]

Hello List,

I'm a fresh subscriber to this list :-)

I'm new to GCC and I'd appreciate if somebody could point me to _all_
files which are responsible for intermediate representation and
constructing it. I don't want to miss
any files which may be crucial and GCC codebase seems to be quite... big.

My other question is about intermediate representation as well.
Is intermediate form generated during all compiler passes or _after_
all compiler passes are done?



kind regards
Mateusz Berezecki

Question about testsuit for native 2.95.3 files and procedure.

[J.J.Garcia]

Hi all,

Just gathering info about passing the testsuite for gcc 2.95.3, i've just
downloaded the tarball from GNU and i realize that there is no specific
'testsuite' folder included.

The tarball ftp://ftp.gnu.org/gnu/gcc/gcc-2.95.3/gcc-everything-2.95.3.tar.gz

At the same time, i think there's no specific testsuites for 2.95.3 release
(confirm it) then i've downloaded the testusites from GNU following docs at
http://gcc.gnu.org/install/test.html.

IOW, gcc-2.3.3-testsuite.tar.gz tarball from GNU, not sure if it is the correct
tarball, but decompressing it you can see a 'testsuite' folder plus a
Makefile.in in the root level.

In the README file for that testsuite is recomended to include the 'testsuite'
folder into the GNU Gcc directory, but i dont know what to do with the 
Makefile.in

What i've read about it is to first test the native test and then try with the
cross one. Im in the first stage, that is native testing for 2.95.3.

Should i leave only the 'testsuite' folder placed in the GNU GCC sources and

'make bootstrap' +
'runtest --all --tool gcc --srcdir ../gcc-2.95.3/gcc/testsuite'

or

'make bootstrap' +
'make -k check'

instead?

I'm messed about it.

TIA

J.J. Garcia.

C++ symbol Demangaling

[Pratik Mehta]

Hello,

  I am looking for a C++ ABI implementation with BSD or LGPL like
license. My need is only to demangle the symbol names that are
produced by gcc. By searching the web, I came across libiberty and
libcwd, but It appears that there is some confusion about license and
features of these libraries. I would like to know if someone knows of
demangaling library under above mentioned licenses.

TIA