RE: [discuss] When is RBX used for base pointer?

[Ye, Joey]

Honza,

> Honza said:
> I am bit confused here.  If I wanted a free register in prologue only,
I
> would probably look at the caller saved ones.  But I gues it is just
> typo.

> I don't see much value in making the register callee-saved especially
if
> you say that virtual reg (pseudo?) is used afterward.
I'm sorry for the confusing word. But I did mean callee-save register,
in case none caller-save register is available. For i386, eax, edx and
ecx can all be used to pass register parameters. So there must be a
callee-save register in stock. Due to faked bug we said only callee-save
register can be used. It has been clarified now.


> When you just need a temporary in prologue, I think you can go with
RAX
> in most cases getting shortest code. It is used by x86-64 stdargs
> prologue and by i386 regparm. You can improve bit broken
> ix86_eax_live_at_start_p to test this. Using alternative choice if RAX
> is taken.
In case callee-save registers are available, ECX is a good candidate for
i386 because it is the latest register to use for parameter passing. RAX
is a good candiate for x86_64.

Thanks - Joey

optimizing predictable branches on x86

[Nick Piggin]

Hi list,

gcc-4.3 appears to make quite heavy use of cmov to eliminate
conditional branches on x86(-64) architecture, even for those
branches that are determined to be predictable.

The problem with this is that the data dependancy introduced
by the cmov can restrict execution, wheras a predicted branch
will not. The Intel manual says not to use cmov for
predictable branches.

I have a test case which I /believe/ demonstrates that a cond
jump is not a great deal slower in the case where there are
no data dependancy hazards hit, and can be quite a bit faster
in the case where there is a dependancy -- if the branch is
predictable. It also shows that if the branch is unpredictable
then cmov can be a good win (as expected).

Compiled with:
gcc-4.3 -O3 -falign-functions=64 -falign-loops=64 -falign-jumps=64
-falign-labels=64 -march=core2/opteron

Opteron:
 no deps,   predictable -- Ccode took   8.92ns per iteration
 no deps,   predictable -- cmov code took   9.09ns per iteration
 no deps,   predictable -- jmp  code took   9.60ns per iteration[1]
has deps,   predictable -- Ccode took  20.04ns per iteration
has deps,   predictable -- cmov code took  18.09ns per iteration
has deps,   predictable -- jmp  code took  14.97ns per iteration[2]
 no deps, unpredictable -- Ccode took   8.92ns per iteration
 no deps, unpredictable -- cmov code took   9.09ns per iteration
 no deps, unpredictable -- jmp  code took  15.19ns per iteration[3]
has deps, unpredictable -- Ccode took  32.07ns per iteration
has deps, unpredictable -- cmov code took  33.15ns per iteration
has deps, unpredictable -- jmp  code took  69.04ns per iteration[4]

[1] jmp is slightly slower, can it be improved?
[2] nice improvement here
[3] mispredict penalty, cmov is a big win
[4] mispredict which includes load missing cache!

Core2:
 no deps,   predictable -- Ccode took   4.24ns per iteration
 no deps,   predictable -- cmov code took   4.27ns per iteration
 no deps,   predictable -- jmp  code took   4.24ns per iteration
has deps,   predictable -- Ccode took   6.04ns per iteration
has deps,   predictable -- cmov code took   6.59ns per iteration
has deps,   predictable -- jmp  code took   5.04ns per iteration
 no deps, unpredictable -- Ccode took   4.24ns per iteration
 no deps, unpredictable -- cmov code took   4.25ns per iteration
 no deps, unpredictable -- jmp  code took   8.79ns per iteration
has deps, unpredictable -- Ccode took  49.78ns per iteration
has deps, unpredictable -- cmov code took  50.28ns per iteration
has deps, unpredictable -- jmp  code took  75.67ns per iteration

Core2 follows a similar pattern, although it's not seeing any
slowdown in the "no deps, predictable, jmp" case like K8 does.

Any comments? (please cc me) Should gcc be using conditional jumps
more often eg. in the case of __builtin_expect())?

Thanks,
Nick
//#define noinline __attribute__((noinline))
#define noinline
#define likely(x) __builtin_expect(!!(x), 1)

static noinline int test_cmov(int a, int b)
{
	int ret;

	asm volatile (
		"cmpl	%1, %2\n\t"
		"cmovle	%2, %1\n\t"
		"movl	%1, %0\n\t"
		: "=r" (ret)
		: "r" (a), "r" (b));

	return ret;
}

static noinline int test_jmp(int a, int b)
{
	int ret;

	asm volatile (
		"cmpl	%1, %2\n\t"
		"jle	1f\n\t"
		"movl	%1, %0\n\t"
		"2:\n\t"
		".subsection 1\n\t"
		"1:\n\t"
		"movl	%2, %0\n\t"
		"jmp	2b\n\t"
		".previous\n\t"
		: "=r" (ret)
		: "r" (a), "r" (b));

	return ret;
}

static noinline int test_c(int a, int b)
{
	int ret;

	if (likely(a < b))
		ret = a;
	else
		ret = b;

	return ret;
}

#define ITERS	1
#define SIZE	(4*1024*1024)
static int array1[SIZE];
static int array2[SIZE];
static volatile int result[SIZE];

#include 
#include 
#include 
#include 

static void print_time(const char *str, struct timeval *s, struct timeval *e, unsigned long iters)
{
	unsigned long long us, ns;
	double ns_iter;

	us = 100*(e->tv_sec - s->tv_sec) + (e->tv_usec - s->tv_usec);
	ns = us * 1000;
	ns_iter = (double)ns / iters;
	ns /= iters;

	printf("%s took % 6.2lfns per iteration\n", str, ns_iter);
}

int main(void)
{
	struct timeval s, e;
	int i;

	assert(test_cmov(1, 2) == test_c(1, 2));
	assert(test_cmov(1, 1) == test_c(1, 1));
	assert(test_cmov(2, 1) == test_c(2, 1));
	assert(test_jmp(1, 2) == test_c(1, 2));
	assert(test_jmp(1, 1) == test_c(1, 1));
	assert(test_jmp(2, 1) == test_c(2, 1));

	for (i = 0; i < SIZE; i++) {
		array1[i] = i;
		array2[i] = i + 1;
		result[i] = 0;
	}

	gettimeofday(&s, NULL);
	for (i = 0; i < ITERS; i++) {
		result[i%SIZE] = test_c(array1[i%SIZE], array2[i%SIZE]);
	}
	gettimeofday(&e, NULL);
	print_time(" no deps,   predictable -- Ccode", &s, &e, ITERS);

	gettimeofday(&s, NULL);
	for (i = 0; i < ITERS; i++) {
		result[i%SIZE] = test_cmov(array1[i%SIZE], array2[i%SIZE]);
	}
	gettimeofday(&e, NULL);
	print_time(" no deps,   predictable -- cmov code", &s, &e, ITERS);

	gettimeofday(&s, NULL);
	for (i = 0; i < ITERS; i++) {
		result[i%SIZE] = test_jmp(array1[i%SIZ

gcc-4.1-20080225 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch 
revision 132645

You'll find:

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

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

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

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

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

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

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

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

Diffs from 4.1-20080218 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: Bootstrap failure on x86_64

[Richard Guenther]

On Mon, 25 Feb 2008, H.J. Lu wrote:

> Uros failed with --enable-checking=release and I failed with
> --enable-checking=assert.
> You can try either one.

That reproduces it.  I have reverted the patch for now.

Richard.

Re: When the R.I.P. of 4.1.x branch for?

[Samuel Tardieu]

> "JCP" == J C Pizarro <[EMAIL PROTECTED]> writes:

JCP> I want to see a comparison of performances between 4.1.x, 4.2.x
JCP> and 4.4.x to know how they have been evolved.

What prevents you from doing the comparaison yourself using SVN?

  Sam
-- 
Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/

global declarations

[Dasarath Weeratunge]

Once the files have been completely parsed, how can I traverse through
all global declarations (e.g. types and variables) ? I can find the
functions by traversing the call graph but would like to know how to
do the same for types and variables. Also is there a way to find a
decl from its UID?

Thanks.
-- dasarath

Re: GTY as attributes

[Tom Tromey]

> "Taras" == Taras Glek <[EMAIL PROTECTED]> writes:

Taras> typedef struct Name GTY(()) {
Taras> };
Taras> These would parse fine as attributes if they were more like
Taras> typedef struct GTY(()) Name  {
Taras> };
Taras> Would you be willing to accept such a change?

I couldn't approve or reject a patch to do this, but I think the
precise syntax of GTY's does not matter much provided that nothing
regresses -- i.e., gengtype works, the docs are updated, etc.

If you wrote a patch to do this, I would support it.

If you do decided to do this, you might want to get started on your
GCC paperwork early, before the patch is finished.

Taras> Another possible benefit of raising GTYs to attribute status would be
Taras> that other projects could do compile-time reflection similar to what
Taras> GCC does in a semi-formal way.

I don't think we want to expose GTY stuff outside of GCC.

Instead I think other project should use something like dehydra or
gcc-xml or whatever to extract whatever metadata they need.  AIUI the
reason we didn't do this for gengtype is just that we needed to
support building with other compilers.

Tom

Re: Bootstrap failure on x86_64

[H.J. Lu]

On Mon, Feb 25, 2008 at 12:13 PM, Richard Guenther <[EMAIL PROTECTED]> wrote:
>
> On Mon, 25 Feb 2008, Richard Guenther wrote:
>
>  > On Mon, 25 Feb 2008, H.J. Lu wrote:
>  >
>  > > On Mon, Feb 25, 2008 at 9:55 AM, Uros Bizjak <[EMAIL PROTECTED]> wrote:
>  > > > Hello!
>  > > >
>  > > >  A recent patch introduced this bootstrap breakage on x86_64:
>  > > >
>  > > >  Revision: 132629
>  > > >
>  > > >  Last Changed Author: rguenth
>  > > >  Last Changed Rev: 132629
>  > > >  Last Changed Date: 2008-02-25 16:10:34 +0100 (Mon, 25 Feb 2008)
>  > > >  Properties Last Updated: 2008-02-19 17:18:53 +0100 (Tue, 19 Feb 2008)
>  > > >
>  > > >  Configured with ../gcc-svn/trunk/configure
>  > > >  --enable-languages=c,c++,fortran --enable-checking=release
>  > > >
>  > >
>  > > I have verified that  revision 132629 is the cause. Is there a bug
>  > > report for it?
>  >
>  > I will see if I can pinpoint the cause.  Otherwise I'll just revert
>  > the patch.  Bootstrap & testing was ok for me on x86_64 with checking
>  > enabled and all languages + ada enabled.
>
>  A suggested --enable-checking=yes,gcac works fine for me as well
>  (c, c++ only).  Any further ideas on how to narrow this down?  Supposedly
>  this may be the same cause as the reason for
>

Uros failed with --enable-checking=release and I failed with
--enable-checking=assert.
You can try either one.


H.J.

Re: Bootstrap failure on x86_64

[Richard Guenther]

On Mon, 25 Feb 2008, Richard Guenther wrote:

> On Mon, 25 Feb 2008, H.J. Lu wrote:
> 
> > On Mon, Feb 25, 2008 at 9:55 AM, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> > > Hello!
> > >
> > >  A recent patch introduced this bootstrap breakage on x86_64:
> > >
> > >  Revision: 132629
> > >
> > >  Last Changed Author: rguenth
> > >  Last Changed Rev: 132629
> > >  Last Changed Date: 2008-02-25 16:10:34 +0100 (Mon, 25 Feb 2008)
> > >  Properties Last Updated: 2008-02-19 17:18:53 +0100 (Tue, 19 Feb 2008)
> > >
> > >  Configured with ../gcc-svn/trunk/configure
> > >  --enable-languages=c,c++,fortran --enable-checking=release
> > >
> > 
> > I have verified that  revision 132629 is the cause. Is there a bug
> > report for it?
> 
> I will see if I can pinpoint the cause.  Otherwise I'll just revert
> the patch.  Bootstrap & testing was ok for me on x86_64 with checking
> enabled and all languages + ada enabled.

A suggested --enable-checking=yes,gcac works fine for me as well
(c, c++ only).  Any further ideas on how to narrow this down?  Supposedly
this may be the same cause as the reason for

  /* We should never try to re-insert a decl with the same uid.
 ???  The C++ frontend breaks this invariant.  Hopefully in a
 non-fatal way, so just overwrite the slot in this case.  */
#if 0
  gcc_assert (!*slot);
#endif

?

Thanks,
Richard.

Re: Idea to gain the time of wider testing.

[Robert Dewar]

Ben Elliston wrote:

On Fri, 2008-02-22 at 20:56 +0100, J.C. Pizarro wrote:


I've ideas when there are repetitive processes as e.g. the testing processes.

Q1. Why to lose time testing the same reiterated files that always had worked
for many months or years?


To use an old expression, "past performance is no guarantee of future
performance".  Just because a test has passed hundreds of times before
does not mean that a small change will not introduce a regression.  In
my experience, sometimes regressions  occur where I least expect them.


I very much agree with this, and as machines get faster, more tests can
be run more easily anyway. At first with our internal GNAT suite, we
did separate off tests that had passed for a long time into a separate
suite, run only daily instead of every checkin, but we have found that
with very fast multi-processors available, the test suite takes less
time than it used to, even though it is growing rapidly, and even though
we have put back almost all of those segregated tests.


Ben

Re: Bootstrap failure on x86_64

[Richard Guenther]

On Mon, 25 Feb 2008, H.J. Lu wrote:

> On Mon, Feb 25, 2008 at 9:55 AM, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> > Hello!
> >
> >  A recent patch introduced this bootstrap breakage on x86_64:
> >
> >  Revision: 132629
> >
> >  Last Changed Author: rguenth
> >  Last Changed Rev: 132629
> >  Last Changed Date: 2008-02-25 16:10:34 +0100 (Mon, 25 Feb 2008)
> >  Properties Last Updated: 2008-02-19 17:18:53 +0100 (Tue, 19 Feb 2008)
> >
> >  Configured with ../gcc-svn/trunk/configure
> >  --enable-languages=c,c++,fortran --enable-checking=release
> >
> 
> I have verified that  revision 132629 is the cause. Is there a bug
> report for it?

I will see if I can pinpoint the cause.  Otherwise I'll just revert
the patch.  Bootstrap & testing was ok for me on x86_64 with checking
enabled and all languages + ada enabled.

Richard.

Re: Bootstrap failure on x86_64

[H.J. Lu]

On Mon, Feb 25, 2008 at 9:55 AM, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> Hello!
>
>  A recent patch introduced this bootstrap breakage on x86_64:
>
>  Revision: 132629
>
>  Last Changed Author: rguenth
>  Last Changed Rev: 132629
>  Last Changed Date: 2008-02-25 16:10:34 +0100 (Mon, 25 Feb 2008)
>  Properties Last Updated: 2008-02-19 17:18:53 +0100 (Tue, 19 Feb 2008)
>
>  Configured with ../gcc-svn/trunk/configure
>  --enable-languages=c,c++,fortran --enable-checking=release
>

I have verified that  revision 132629 is the cause. Is there a bug
report for it?


H.J.

Re: Idea to gain the time of wider testing.

[Ben Elliston]

On Fri, 2008-02-22 at 20:56 +0100, J.C. Pizarro wrote:

> I've ideas when there are repetitive processes as e.g. the testing processes.
> 
> Q1. Why to lose time testing the same reiterated files that always had worked
> for many months or years?

To use an old expression, "past performance is no guarantee of future
performance".  Just because a test has passed hundreds of times before
does not mean that a small change will not introduce a regression.  In
my experience, sometimes regressions  occur where I least expect them.

Ben

Re: SSA alias representation

[Diego Novillo]

On Mon, Feb 25, 2008 at 10:25, Fran Baena <[EMAIL PROTECTED]> wrote:
> If a name tag is associated to a ssa name, ¿when does it make sense to
>  version a name tag? (If it does)

When there are no symbols in the pointer's points-to set.


Diego.

Re: SSA alias representation

[Fran Baena]

If a name tag is associated to a ssa name, ¿when does it make sense to
version a name tag? (If it does)

2008/2/21, Diego Novillo <[EMAIL PROTECTED]>:
> On 2/21/08 1:13 PM, Fran Baena wrote:
>  > 2008/2/21, Diego Novillo <[EMAIL PROTECTED]>:
>  >> On 2/19/08 2:27 PM, Fran Baena wrote:
>  >>  > Hi everybody,
>  >>  >
>  >>  > i am studing how gcc carries out Alias Representation and some 
> questions appear.
>  >>  >
>  >>  > For instance, given this code portion:
>  >>  >
>  >>  >  if ( ... )
>  >>  >p  = &a;
>  >>  >  else
>  >>  >if ( ... )
>  >>  >  p = &b;
>  >>  >else
>  >>  >  p = &c;
>  >>  >
>  >>  >  a = 5;
>  >>  >  b = 3;
>  >>  >  d = *p4;
>  >>  >
>  >>  > My questions are:
>  >>  >
>  >>  > - both p like *p need a Name Memory Tag structure? It is enough with 
> only one?
>  >>
>  >>
>  >> Pointer dereferences do not receive NMTs, only the pointers.  So a name
>  >>  tag will be associated with the SSA name resulting from the PHI node
>  >>  created at the end of that if() tree.
>  >
>  > And this name tag is versioned too, like this:
>  >  if ( ... )
>  > p  = &a;   (NMTv1 associated to p)
>  >  else
>  >  if ( ... )
>  > p = &b;(NMTv2 associated to p)
>  >  else
>  > p = &c;(NMTv3 associated to p)
>  >
>
> No.  None of these SSA names are dereferenced so no name tag is created
>  for them.  The only SSA name with a name tag will be the one produced by
>  the PHI.
>
>  See the output of -fdump-tree-salias-vops-blocks.  That will show you
>  the results of the first alias analysis run.
>
>
>  > To organize temporarily the passes. Firstly alias analysis is
>  > computed, it is followed by ssa form, and after that the memory ssa
>  > web, aren't they?
>
>
> No.  First SSA then alias analysis then the memory SSA
>
>
>  > Where could i find all the passes applied and their order?
>
>
> passes.c:init_optimization_passes.
>
>
>  > What is register SSA form? Is it the standard SSA form explained in
>  > "Efficiently computing static single assignment form and the control
>  > dependence graph (cytron91)"?
>
>
> Yes.  It's the traditional rewriting form.  The memory SSA web is the
>  factored use-def chains by Wolfe.
>
>
>  See the tutorials in http://gcc.gnu.org/wiki/GettingStarted, all this is
>  described there.
>
>
>
>  Diego.
>

Bootstrap failure on x86_64

[Uros Bizjak]

Hello!

A recent patch introduced this bootstrap breakage on x86_64:

Entering directory 
`/home/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include'

if [ ! -d "./x86_64-unknown-linux-gnu/bits/stdc++.h.gch" ]; then \
 mkdir -p ./x86_64-unknown-linux-gnu/bits/stdc++.h.gch; \
   fi; \
   /home/uros/gcc-build/./gcc/xgcc -shared-libgcc 
-B/home/uros/gcc-build/./gcc -nostdinc++ 
-L/home/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src 
-L/home/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs 
-B/usr/local/x86_64-unknown-linux-gnu/bin/ 
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem 
/usr/local/x86_64-unknown-linux-gnu/include -isystem 
/usr/local/x86_64-unknown-linux-gnu/sys-include -Winvalid-pch -x 
c++-header -g -O2   -D_GNU_SOURCE   
-I/home/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu 
-I/home/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include 
-I/home/uros/gcc-svn/trunk/libstdc++-v3/libsupc++ -O0 -g 
/home/uros/gcc-svn/trunk/libstdc++-v3/include/precompiled/stdc++.h -o 
x86_64-unknown-linux-gnu/bits/stdc++.h.gch/O0g.gch


In file included from 
/home/uros/gcc-svn/trunk/libstdc++-v3/include/precompiled/stdc++.h:96:
/home/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/valarray:1036: 
internal compiler error: in gt_pch_note_object, at ggc-common.c:256

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
gmake[4]: *** [x86_64-unknown-linux-gnu/bits/stdc++.h.gch/O0g.gch] Error 1
gmake[4]: Leaving directory 
`/home/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include'

gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory 
`/home/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3'

gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory 
`/home/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3'

gmake[1]: *** [all-target-libstdc++-v3] Error 2
gmake[1]: Leaving directory `/home/uros/gcc-build'
gmake: *** [all] Error 2


> svn info

Revision: 132629

Last Changed Author: rguenth
Last Changed Rev: 132629
Last Changed Date: 2008-02-25 16:10:34 +0100 (Mon, 25 Feb 2008)
Properties Last Updated: 2008-02-19 17:18:53 +0100 (Tue, 19 Feb 2008)

Configured with ../gcc-svn/trunk/configure 
--enable-languages=c,c++,fortran --enable-checking=release


Uros.

When the R.I.P. of 4.1.x branch for?

[J.C. Pizarro]

The 4.0.x branch was R.I.P.ed.

Commiting 4.1.x, 4.2.x, 4.3.x and 4.4.x means 4 times of efforts than 3 times.
They are very similar in design, they use TreeSSA, autovectoring, etc.

It's recommended to be online 4.2.x, 4.3.x and 4.4.x branches.

I want to see a comparison of performances between 4.1.x, 4.2.x and 4.4.x
to know how they have been evolved.

   ;)

ObjC 2.0 on the GCC trunk...

[Gregory John Casamento]

Hi guys,

I'm interested in what if any issues exist in bringing ObjC 2.0 to the trunk of 
GCC.   I spoke with someone recently who claimed that there were GPLv3 problems 
with Apple's code, is this correct?

Thanks, GJC
--
Gregory Casamento -- Principal Consultant - OLC, Inc 
# GNUstep Chief Maintainer

4.3 regression: -frtti and #pragma visibility

[Benjamin Smedberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I discovered a GCC 4.3 regression today while compiling Mozilla in debug
mode (with RTTI), and submitted a reduced testcase in PR35368.

I'm happy to submit a patch if somebody can point me in the right direction:
I presume there's a magic tree node somewhere that represents
__class_type_info and needs default-visibility to be explicitly set on it.

- --BDS

- --

Benjamin Smedberg
Platform Guru
Mozilla Corporation
[EMAIL PROTECTED]
http://benjamin.smedbergs.us/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHwuE5SSwGp5sTYNkRAk5xAJkBoqvURocLwwIhI+QCIxDCdACMPwCgoX3X
BIR4f3fYq0htHybJ+WfiRy0=
=Iiqa
-END PGP SIGNATURE-

Re: Redundant logical operations left after early splitting

[hutchinsonandy]

Jeff,

I take your point and will go back over my splitters as I know one 
instance in which a splitter can create such an issue.

(I should checlk for a constant operand after  simplifying an  operand).

In the cases I looked at before this was not the situation.

Each splitter - or subreg lowering potentially creates (or rather 
reveals) another cascade oppertunity - but current pass arrangement 
provide no means to remove them (other than the trivial propagation in 
local-alloc). That seems fundementally wrong.


So all targets that use split or have lowered subregs potentially have 
excess register usage  and instructions (how much - I dont know)


I dont follow how taking  another psuedo inside split helps - that 
still seems to be another cascade that local-alloc will not remove.


As a side issue, if the the current  fwprop bug  - which often only 
propagates one operand, can be fixed, then I may be in better shape 
(since the early pass may then remove any cascades remaining  before it 
hits splitters)


I am looking at my original problem again and trying to find some level 
of earlier optimisation I can use (ie some form of earlier expansion or 
combination). If I can remove some of the cascaded levels before split, 
then things get much better!

But this is not easy.

thank you for your advise







-Original Message-
From: Jeff Law <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; gcc@gcc.gnu.org
Sent: Mon, 25 Feb 2008 4:34 am
Subject: Re: Redundant logical operations left after early splitting


[EMAIL PROTECTED] wrote: 

If I understand correctly: 
> Prop. of "0" causes simplfy-rtx to create NOP from OR Rx,0 
This NOP (deletion?) creates another set of potential uses - as now 
the > prior RHS def now passes straight thru to a new set of uses - but 
we > miss those new uses. (which in the testcase are often 0) 
> I will try fwprop in a few different spots latter and see what, if 

any > changes occur. 
Classic cascading. 
 
I think some of this is an artifact of how your splitters are working. 
You end up creating code which looks like 
 
(set (reg1) (const_int 0) 
(set (reg1) (ior (reg1) (other_reg) 
 
What's important here is that reg1 is being set multiple times. You'd 
be better off if you can twiddle the splitters to avoid this behavior. 
If you need a new pseudo, then get one :-) 
 
Once you do that, local would propagate these things better. That 
still leaves the simplification & nop problem, but I'm pretty sure 
that can be trivially fixed within local without resorting to running 
another forwprop pass after splitting. 
 
Jeff 



More new features than ever.  Check out the new AIM(R) Mail ! - 
http://webmail.aim.com

Re: -mfmovd enabled by default for SH2A but not for SH4

[Kaz Kojima]

"Naveen H.S." <[EMAIL PROTECTED]> wrote:
> Yes, we completely agree that using the option "-mdalign" would solve
> the "address error" problem in the present testcase. We had tried the
> similar way to solve the problem. However, we observed that "-mdlaign"
> option would not guarantee the stack variables to be 8 byte aligned.
> Please refer the following link which explains the same.
> http://gcc.gnu.org/ml/gcc/2008-02/msg00508.html

TARGET_ALIGN_DOUBLE means that PREFERRED_STACK_BOUNDARY is set
to 64.  I remember that such problem exists in older compilers
as Toshi pointed out, but thought that they are fixed on trunk.
You could file it to the bugzilla with your testcase.

Regards,
kaz

Re: need help

[Alexey Zaytsev]

On Mon, Feb 25, 2008 at 3:23 PM, Mag cool <[EMAIL PROTECTED]> wrote:
> hi, i am a beginner in this tech world. i want to learn 1/how to do 
> programming in c in unix or linux. i don't know anything about linux. where 
> to start.
>
Try this book: http://www.advancedlinuxprogramming.com/

>
>
>   
> 
>  Never miss a thing.  Make Yahoo your home page.
>  http://www.yahoo.com/r/hs
>
>

RE: -mfmovd enabled by default for SH2A but not for SH4

[Naveen H.S.]

Hi,

>> Although one can explicitly provide his own fpscr setting as 
>> Christian said and can use appropriate options, defaulting -mdalign
>. for TARGET_SH2A_DOUBLE might be more robust for users.

Yes, we completely agree that using the option "-mdalign" would solve
the "address error" problem in the present testcase. We had tried the
similar way to solve the problem. However, we observed that "-mdlaign"
option would not guarantee the stack variables to be 8 byte aligned.
Please refer the following link which explains the same.
http://gcc.gnu.org/ml/gcc/2008-02/msg00508.html

Regards,
Naveen.H.S.
KPIT Cummins Infosystems Ltd,
Pune (INDIA) 
~~  
Free download of GNU based tool-chains for Renesas' SH, H8, R8C, M16C   
and M32C Series. The following site also offers free technical support  
to its users. Visit http://www.kpitgnutools.com for details.
Latest versions of KPIT GNU tools were released on February 4, 2008.
~~

need help

[Mag cool]

hi, i am a beginner in this tech world. i want to learn how to do programming 
in c in unix or linux. i don't know anything about linux. where to start.


  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

need help

[Mag cool]

hi, i am a beginner in this tech world. i want to learn 1/how to do programming 
in c in unix or linux. i don't know anything about linux. where to start.


  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Re: -mfmovd enabled by default for SH2A but not for SH4

[Kaz Kojima]

"Naveen H.S." <[EMAIL PROTECTED]> wrote:
> Yes, we got this error on SH72513(SH2A) hardware. When the same code
> is run on simulator, the "address error" occurs on encountering the
> "fmov.d" instruction.
[snip]
> It is mentioned that "Double longword data accessed from other than 
> double longword boundary" results in address error.

I thought that fmov.d does two long word accesses as Christian
has pointed out in his comment.
Anyway, the address error on the real hardware would suggest
that the double long word access occurs in your case.

Although one can explicitly provide his own fpscr setting as
Christian said and can use appropriate options, defaulting
-mdalign for TARGET_SH2A_DOUBLE might be more robust for users.

Could you please try the appended patch?  Christian, how does
it look?

Regards,
kaz
--
* config/sh/sh.h (OVERRIDE_OPTIONS): Set MASK_ALIGN_DOUBLE
for TARGET_SH2A_DOUBLE.

--- ORIG/trunk/gcc/config/sh/sh.h   2007-12-07 09:11:38.0 +0900
+++ LOCAL/trunk/gcc/config/sh/sh.h  2008-02-25 19:09:48.0 +0900
@@ -553,7 +553,7 @@ do {
\
 {  \
   sh_cpu = CPU_SH2A;   \
   if (TARGET_SH2A_DOUBLE)  \
-target_flags |= MASK_FMOVD;\
+target_flags |= MASK_FMOVD | MASK_ALIGN_DOUBLE;
\
 }  \
   if (TARGET_SH3)  \
 sh_cpu = CPU_SH3;  \

Re: -mfmovd enabled by default for SH2A but not for SH4

[Christian BRUEL]

Hello,

Looks like you are mixing ABIs. what is you fpscr setting ?

From my understanding, if the fpscr PR bit is set to 0 the 64-bit 
operation behaves as 2 32 bit operations (paired single precision). so I 
don't think you get an address error here.


The well defined behavior of the fmov instruction depends on the 
endianess and the SZ/PR bits setting in the fpscr register. My guess is 
that the default gcc value of 32 bits fmov instruction is the one that 
matches best all sh4 configurations (SZ/PR=1 is even undefined for some 
cores).
Changing its default would be possible if you change your ABI or have 
another multilib setting for startup files. But the current situation is 
that it is usually let to the user to explicitly provide their own fpscr 
setting when then want to change the fpmov size and aligns.


Cheers,

Christian


Naveen H.S. wrote:

Hi,



Have you got this error on the real SH2A-FPU hardware?


Yes, we got this error on SH72513(SH2A) hardware. When the same code
is run on simulator, the "address error" occurs on encountering the
"fmov.d" instruction.



couldn't find any description for 8-byte alignment restriction for
double data on memory in my SH2A manual


Please refer the section 3.3 "address errors" in the SH2A software 
manual at the following link:-

http://documentation.renesas.com/eng/products/mpumcu/rej09b0051_sh2a.pdf
It is mentioned that "Double longword data accessed from other than 
double longword boundary" results in address error.


Regards,
Naveen.H.S.
KPIT Cummins Infosystems Ltd,
Pune (INDIA) 
~~	

Free download of GNU based tool-chains for Renesas' SH, H8, R8C, M16C   
and M32C Series. The following site also offers free technical support  
to its users. Visit http://www.kpitgnutools.com for details.
Latest versions of KPIT GNU tools were released on February 4, 2008.
~~

Re: Redundant logical operations left after early splitting

[Paolo Bonzini]

What's important here is that reg1 is being set multiple times.  You'd
be better off if you can twiddle the splitters to avoid this behavior.
If you need a new pseudo, then get one :-)


I agree with this, but...


Once you do that, local would propagate these things better.  That
still leaves the simplification & nop problem, but I'm pretty sure
that can be trivially fixed within local without resorting to running
another forwprop pass after splitting.


I want to try *moving* forwprop, not add another pass.  Also, fwprop 
could in principle subsume local const/copyprop; it doesn't right now 
because I didn't want to compute def-use chains, but it could be changed 
in the future.


Paolo

Re: Redundant logical operations left after early splitting

[Jeff Law]

[EMAIL PROTECTED] wrote:

If I understand correctly:

Prop. of "0" causes simplfy-rtx to create NOP from OR Rx,0
This NOP (deletion?) creates another set of potential uses -  as now the 
prior RHS def now passes straight thru to a new set of uses  - but we 
miss those new uses. (which in the testcase are often 0)


I will try fwprop in a few different spots latter and see what, if any 
changes occur.

Classic cascading.

I think some of this is an artifact of how your splitters are working.
You end up creating code which looks like


(set (reg1) (const_int 0)
(set (reg1) (ior (reg1) (other_reg)

What's important here is that reg1 is being set multiple times.  You'd
be better off if you can twiddle the splitters to avoid this behavior.
If you need a new pseudo, then get one :-)

Once you do that, local would propagate these things better.  That
still leaves the simplification & nop problem, but I'm pretty sure
that can be trivially fixed within local without resorting to running
another forwprop pass after splitting.

Jeff

RE: -mfmovd enabled by default for SH2A but not for SH4

[Naveen H.S.]

Hi,

>> Have you got this error on the real SH2A-FPU hardware?
Yes, we got this error on SH72513(SH2A) hardware. When the same code
is run on simulator, the "address error" occurs on encountering the
"fmov.d" instruction.

>> couldn't find any description for 8-byte alignment restriction for
>> double data on memory in my SH2A manual
Please refer the section 3.3 "address errors" in the SH2A software 
manual at the following link:-
http://documentation.renesas.com/eng/products/mpumcu/rej09b0051_sh2a.pdf
It is mentioned that "Double longword data accessed from other than 
double longword boundary" results in address error.

Regards,
Naveen.H.S.
KPIT Cummins Infosystems Ltd,
Pune (INDIA) 
~~  
Free download of GNU based tool-chains for Renesas' SH, H8, R8C, M16C   
and M32C Series. The following site also offers free technical support  
to its users. Visit http://www.kpitgnutools.com for details.
Latest versions of KPIT GNU tools were released on February 4, 2008.
~~