Why no strings in error messages?

Why no strings in error messages?

[Bradley Lucier]

I've never seen the answer to the following question:  Why do some  
versions of gcc that I build not have string substitutions in error  
messages?

I get things like this:

[lucier@lambda-head lib]$ /pkgs/gcc-mainline/bin/gcc -mcpu=970 -m64 - 
fschedule-insns -Wno-unused -O1 -fno-math-errno -fschedule-insns2 - 
fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer - 
fPIC -fno-common -I"../include" -c _thread-test.i -save-temps
_thread.c: In function â:
_thread.c:10035:146: error: â undeclared (first use in this function)
_thread.c:10035:146: error: (Each undeclared identifier is reported  
only once
_thread.c:10035:146: error: for each function it appears in.)

It makes cutting down a test case for a bug report a bit of guess and  
hack.

And an unrelated question:  I've found on some tests on x86-64 that - 
fschedule-insns added to -O1 speeds up some of my codes impressively,  
but on x86-64-linux and powerpc64-linux I've had problems finding  
spill registers and I've also been getting stuff like

/pkgs/gcc-mainline/bin/gcc -mcpu=970 -m64 -fschedule-insns -save- 
temps -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping- 
math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno- 
common   -I"../include" -c -o "_thread.o" -I. -DHAVE_CONFIG_H - 
D___GAMBCDIR="\"/usr/local/Gambit-C\"" -D___SYS_TYPE_CPU="\"powerpc64 
\"" -D___SYS_TYPE_VENDOR="\"unknown\"" -D___SYS_TYPE_OS="\"linux-gnu 
\"" -D___CONFIGURE_COMMAND="\"./configure CC=/pkgs/gcc-mainline/bin/ 
gcc -mcpu=970 -m64 -fschedule-insns\"" -D___OBJ_EXTENSION="\".o\"" - 
D___EXE_EXTENSION="\"\"" -D___PRIMAL _thread.c -D___LIBRARY
_thread.c: In function â:
_thread.c:15556:1: error: insn does not satisfy its constraints:
(insn 614 220 216 26 _thread.c:15462 (set (reg:DF 20 20)
         (mem:DF (plus:DI (reg:DI 23 23 [orig:199 D.20368 ] [199])
                 (const_int 23 [0x17])) [0 S8 A64])) 357  
{*movdf_hardfloat64} (nil))
_thread.c:15556:1: internal compiler error: in  
reload_cse_simplify_operands, at postreload.c:396

Actually, I haven't been able to get Gambit to build on any  
architecture I've tried with -fschedule-insns on the command line.

So, is -fschedule-insns an option to be avoided?

Brad

Re: Why no strings in error messages?

[Ian Lance Taylor]

Bradley Lucier <lucier@math.purdue.edu> writes:

> I've never seen the answer to the following question:  Why do some
> versions of gcc that I build not have string substitutions in error
> messages?

Perhaps you configured with --disable-intl?


> So, is -fschedule-insns an option to be avoided?

-fschedule-insns should be avoided on Intel architectures.  In general
-fschedule-insns tends to increase register lifespan, and because of the
small number of available registers this can sometimes befuddle the
register allocator, especially when asm instructions as used.

On PPC -fschedule-insns is normally beneficial, and it is turned on by
-O2.

Ian

Re: Why no strings in error messages?

[Richard Earnshaw]

On Wed, 2009-08-26 at 09:00 -0400, Bradley Lucier wrote:
> I've never seen the answer to the following question:  Why do some  
> versions of gcc that I build not have string substitutions in error  
> messages?
> 
> I get things like this:
> 
> [lucier@lambda-head lib]$ /pkgs/gcc-mainline/bin/gcc -mcpu=970 -m64 - 
> fschedule-insns -Wno-unused -O1 -fno-math-errno -fschedule-insns2 - 
> fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer - 
> fPIC -fno-common -I"../include" -c _thread-test.i -save-temps
> _thread.c: In function â:
> _thread.c:10035:146: error: â undeclared (first use in this function)
> _thread.c:10035:146: error: (Each undeclared identifier is reported  
> only once
> _thread.c:10035:146: error: for each function it appears in.)

Your locale is set up to generate something your terminal can't display
properly (I've seen this myself).

Either fix your terminal to display the extended char-set properly, or
run your compiler with a simpler locale, eg:

export LANG=c
gcc ...

should do the trick.

If you want to prove to yourself that the variables are there pass the
output through 'od -c'

R.

Re: Why no strings in error messages?

[Michael Meissner]

On Wed, Aug 26, 2009 at 06:30:44AM -0700, Ian Lance Taylor wrote:
> Bradley Lucier <lucier@math.purdue.edu> writes:
> 
> > I've never seen the answer to the following question:  Why do some
> > versions of gcc that I build not have string substitutions in error
> > messages?
> 
> Perhaps you configured with --disable-intl?
> 
> 
> > So, is -fschedule-insns an option to be avoided?
> 
> -fschedule-insns should be avoided on Intel architectures.  In general
> -fschedule-insns tends to increase register lifespan, and because of the
> small number of available registers this can sometimes befuddle the
> register allocator, especially when asm instructions as used.

When I worked at AMD, I was starting to suspect that it may be more beneficial
to re-enable the first schedule insns pass if you were compiling in 64-bit
mode, since you have more registers available, and the new registers do not
have hard wired uses, which in the past always meant a lot of spills (also, the
default floating point unit is SSE instead of the x87 stack).  I never got
around to testing this before AMD and I parted company.

> On PPC -fschedule-insns is normally beneficial, and it is turned on by
> -O2.
> 
> Ian

-- 
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meissner@linux.vnet.ibm.com

Re: Why no strings in error messages?

[Paolo Bonzini]

> When I worked at AMD, I was starting to suspect that it may be more beneficial
> to re-enable the first schedule insns pass if you were compiling in 64-bit
> mode, since you have more registers available, and the new registers do not
> have hard wired uses, which in the past always meant a lot of spills (also, the
> default floating point unit is SSE instead of the x87 stack).  I never got
> around to testing this before AMD and I parted company.

Unfortunately, hardwired use of %ecx for shifts is still enough to kill 
-fschedule-insns on AMD64.

Paolo

Re: Why no strings in error messages?

[Paolo Bonzini]

> When I worked at AMD, I was starting to suspect that it may be more beneficial
> to re-enable the first schedule insns pass if you were compiling in 64-bit
> mode, since you have more registers available, and the new registers do not
> have hard wired uses, which in the past always meant a lot of spills (also, the
> default floating point unit is SSE instead of the x87 stack).  I never got
> around to testing this before AMD and I parted company.

Unfortunately, hardwired use of %ecx for shifts is still enough to kill 
-fschedule-insns on AMD64.

Paolo

Re: Why no strings in error messages?

[Bradley Lucier]

On Wed, 2009-08-26 at 20:38 +0200, Paolo Bonzini wrote:
> 
> > When I worked at AMD, I was starting to suspect that it may be more beneficial
> > to re-enable the first schedule insns pass if you were compiling in 64-bit
> > mode, since you have more registers available, and the new registers do not
> > have hard wired uses, which in the past always meant a lot of spills (also, the
> > default floating point unit is SSE instead of the x87 stack).  I never got
> > around to testing this before AMD and I parted company.
> 
> Unfortunately, hardwired use of %ecx for shifts is still enough to kill 
> -fschedule-insns on AMD64.

The AMD64 Architecture manual I found said that various combinations of
the RSI, RDI, and RCX registers are used implicitly by ten instructions
or prefixes, and RBX is used by XLAT, XLATB.  So it appears that there
are 12 general-purpose registers available for allocation.

Are 12 registers not enough, in principle, to do scheduling before
register allocation?  I was getting a 15% speedup on some numerical
codes, as pre-scheduling spaced out the vector loads among the
floating-point computations.

Brad

Re: Why no strings in error messages?

[Ian Lance Taylor]

Bradley Lucier <lucier@math.purdue.edu> writes:

> Are 12 registers not enough, in principle, to do scheduling before
> register allocation?  I was getting a 15% speedup on some numerical
> codes, as pre-scheduling spaced out the vector loads among the
> floating-point computations.

If you are getting that kind of speedup (which I personally did not
expect) then this is clearly worth pursuing.  It should be possible to
make it work at least in 64-bit mode.  I recommend that you file a bug
report or two for cases which fail when using -fschedule-insns.

Ian

Re: Why no strings in error messages?

[Bradley Lucier]

On Wed, 2009-08-26 at 17:12 -0700, Ian Lance Taylor wrote:

> If you are getting that kind of speedup (which I personally did not
> expect) then this is clearly worth pursuing.  It should be possible to
> make it work at least in 64-bit mode.  I recommend that you file a bug
> report or two for cases which fail when using -fschedule-insns.

Thanks, I've added some details of the speedup (with code differences)
to the end of PR33928 and I've reported the two different failures (for
x86-64 and ppc64) in PR41164 and PR41176.

Brad

Re: Why no strings in error messages?

[Andi Kleen]

Bradley Lucier <lucier@math.purdue.edu> writes:

> and RBX is used by XLAT, XLATB. 

XLAT* is generally not used anymore, certainly not in gcc generated code.

> Are 12 registers not enough, in principle, to do scheduling before
> register allocation? 

You want to limit gcc to only 12 registers?

> I was getting a 15% speedup on some numerical

That would assume that only using 12 registers doesn't cause
slowdowns elsewhere, which is likely in fact.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: Why no strings in error messages?

[Gabriel Paubert]

On Wed, Aug 26, 2009 at 03:02:44PM -0400, Bradley Lucier wrote:
> On Wed, 2009-08-26 at 20:38 +0200, Paolo Bonzini wrote:
> > 
> > > When I worked at AMD, I was starting to suspect that it may be more beneficial
> > > to re-enable the first schedule insns pass if you were compiling in 64-bit
> > > mode, since you have more registers available, and the new registers do not
> > > have hard wired uses, which in the past always meant a lot of spills (also, the
> > > default floating point unit is SSE instead of the x87 stack).  I never got
> > > around to testing this before AMD and I parted company.
> > 
> > Unfortunately, hardwired use of %ecx for shifts is still enough to kill 
> > -fschedule-insns on AMD64.
> 
> The AMD64 Architecture manual I found said that various combinations of
> the RSI, RDI, and RCX registers are used implicitly by ten instructions
> or prefixes, and RBX is used by XLAT, XLATB.  So it appears that there
> are 12 general-purpose registers available for allocation.

XLATB is essentially useless (well maybe had some uses back in 16 bit days, 
when only a few registers could be used for addressing) and never generated
by GCC. 

However %ebx is used for PIC addressing in 32 bit mode so it is not 
always free either (I don't know about PIE code).

In 64 bit mode, PIC/PIE use PC relative addressing, so this gives 
you actually 9 more free registers than in 32 bit mode.

However for some reason you glossed over the case of integer division
which always use %edx and %eax. This is true even when dividing by a 
constant (non power of 2) in which case gcc will often use a widening 
multiply instead, whose results are in %edx:%eax, so it's almost a wash 
in terms of fixed register usage (not exactly, the divisions use %edx:%eax 
as dividends and need the divisor somewhere else, while the widening
multiply use %eax as one input but %edx can be used for the other).

(As a side note, %edx and %eax are also special with regard to I/O port
accesses but this is only of interest in device drivers).

> Are 12 registers not enough, in principle, to do scheduling before
> register allocation? 

I don't know, but I would say that you have about 14 registers
for address computations/indexing since you seem to be interested
in FP code. I would think that it is sufficient for many inner
loops (but not all, it really depends on the number of arrays
that you access and the number of independant indexes that
you have to keep).

> I was getting a 15% speedup on some numerical
> codes, as pre-scheduling spaced out the vector loads among the
> floating-point computations.

Well vector loads and floating point computations do not have anything 
to do with integer register choices. The 16 FP registers are 
nicely orthogonal (compared to the real nightmare that the x87 stack was).
In practice you schedule on 16 FP registers and 14 (15 if you omit
the frame pointer) addressing/indexing/counting registers.

In this type of code there are typically very few instructions with
fixed register constraints, and the less likely are the string
instructions. Shifts of variable amount and integer divides
are still possible, but unlikely.

	Gabriel