Re: Some Linux patches

Re: Some Linux patches

[H.J. Lu]

> 
>   In message <m0x3iUK-0004efC@ocean.lucon.org>you write:
>   > > 
>   > > > 	* config/alpha/linux.h (DEFAULT_VTABLE_THUNKS): New. Defined
>   > > > 	as 1.
>   > > 
>   > > This should not be unconditional.  It is wrong for alpha-linux-ecoff
>   > > (not that I think anyone will notice) and glibc1.
>   > > 
>   > 
>   > If that is the case, we should have alpha*-*-linux-gnulibc1*
>   > and alpha*-*-linux-gnu* in configure.in. When it is done, I
>   > can make a new patch for it.
> Until we have that code I'm pulling the alpha/linux.h patch out.
> 
> Jeff
> 
> 

Ok. Here is a real patch. It also deals with alpha*-*-linux-gnulibc1.
But I don't know how to check alpha*-*-linux-gnulibc1 in config.guess.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)
--
Wed Aug 27 09:00:28 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)

	* configure.in (alpha*-*-linux-gnulibc1): New target. Add
	t-linux-gnulibc1 to tmake_file. No thread support.

	* config/alpha/elf.h (DEFAULT_VTABLE_THUNKS): New. Defined as 1
	if USE_GNULIBC_1 is not defined.
	(LINK_SPEC): Use /lib/ld-gnu.so.1 as dynamic linker name if
	USE_GNULIBC_1 is defined.

Index: gcc/configure.in
===================================================================
RCS file: /home/work/cvs/gnu/egcs/gcc/configure.in,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 configure.in
--- configure.in	1997/08/26 00:20:40	1.1.1.1
+++ configure.in	1997/08/27 16:12:25
@@ -273,6 +282,17 @@
 		fixincludes=Makefile.in
 		gas=yes gnu_ld=yes
 		;;
+	alpha*-*-linux-gnulibc1)
+		tm_file="${tm_file} alpha/linux.h alpha/elf.h"
+		xm_file="${xm_file} alpha/xm-linux.h"
+		target_cpu_default="MASK_GAS"
+		gas=no
+		tmake_file="t-linux t-linux-gnulibc1 alpha/t-linux"
+		xmake_file=none
+		fixincludes=Makefile.in
+		extra_parts="crtbegin.o crtbeginS.o crtend.o crtendS.o"
+		gas=yes gnu_ld=yes
+		;;
 	alpha*-*-linux-gnu*)
 		tm_file="${tm_file} alpha/linux.h alpha/elf.h"
 		xm_file="${xm_file} alpha/xm-linux.h"
Index: gcc/config/alpha/elf.h
===================================================================
RCS file: /home/work/cvs/gnu/egcs/gcc/config/alpha/elf.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 elf.h
--- elf.h	1997/08/26 00:20:43	1.1.1.1
+++ elf.h	1997/08/27 16:16:51
@@ -38,6 +38,19 @@
 -D__alpha -D__alpha__ -D__linux__ -D__linux -D_LONGLONG -Dlinux -Dunix \
 -Asystem(linux) -Acpu(alpha) -Amachine(alpha) -D__ELF__"
 
+#ifdef USE_GNULIBC_1
+#undef LINK_SPEC
+#define LINK_SPEC "-m elf64alpha -G 8 %{O*:-O3} %{!O*:-O1}	\
+  %{shared:-shared}						\
+  %{!shared:							\
+    %{!static:							\
+      %{rdynamic:-export-dynamic}				\
+      %{!dynamic-linker:-dynamic-linker /lib/ld-gnu.so.1}}	\
+    %{static:-static}}"
+#else
+#undef DEFAULT_VTABLE_THUNKS
+#define DEFAULT_VTABLE_THUNKS 1
+
 #undef LINK_SPEC
 #define LINK_SPEC "-m elf64alpha -G 8 %{O*:-O3} %{!O*:-O1}	\
   %{shared:-shared}						\
@@ -46,6 +59,7 @@
       %{rdynamic:-export-dynamic}				\
       %{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2}}	\
     %{static:-static}}"
+#endif
 
 /* Output at beginning of assembler file.  */
 

Re: [REQ] If the x86 people could do something about this...

[Jeffrey A Law]

  In message <Pine.SOL.3.90.970827143446.6629G-100000@tracy.informatik.rwth-aac
hen.de>you write:
  > > Yes, you have to know more about what registers are free at any
  > > given insn, but after reload this can be easily computed, and
  > > such information could be quite valueable on other ports as well.
  > 
  > How about a scheme like this: Describe instructions that can be split this
  > way by adding a (clobber (match_scratch:SI "=&Xr")). That should explain
  > to register allocation and reload that the instruction does not actually
  > need a scratch register, but a later pass could analyze this kind of
  > pattern and add the appropriate scratch registers, then split the
  > instructions.
I guess it sounds reasonable.  I would think something like this
would belong in sched since it already has the register live/dead
info and splitting code.

jeff

Re: [REQ] If the x86 people could do something about this...

[Bernd Schmidt]

> Yea, I briefly looked at that code at one time, and couldn't figure out
> how it was significantly different from instruction splitting.

It is not. I think it would be possible to do something quite similar
with instruction splitting.

> Yes, you have to know more about what registers are free at any
> given insn, but after reload this can be easily computed, and
> such information could be quite valueable on other ports as well.

How about a scheme like this: Describe instructions that can be split this
way by adding a (clobber (match_scratch:SI "=&Xr")). That should explain
to register allocation and reload that the instruction does not actually
need a scratch register, but a later pass could analyze this kind of
pattern and add the appropriate scratch registers, then split the
instructions.

Bernd

Re: [REQ] If the x86 people could do something about this...

[Jeffrey A Law]

  In message <Pine.SOL.3.90.970826141735.2901L-100000@maigret.informatik.rwth-a
achen.de>you write:
  > That is correct. Small constants make for smaller code, but that doesn't
  > affect performance on the recent CPUs (apart from code cache issues).
OK.

  > You don't want to load constants in registers before register allocation
  > on the x86, since that would increase register pressure too much. However,
  > after reload, it would be a win to do cse on some commonly used constants
  > and memory locations.
Sounds reasonable.

  > The Intel patches in pgcc do that; they call it "riscifying" instructions.
  > They can change
Yea, I briefly looked at that code at one time, and couldn't figure out
how it was significantly different from instruction splitting.

Yes, you have to know more about what registers are free at any
given insn, but after reload this can be easily computed, and
such information could be quite valueable on other ports as well.


Jeff

Re: [REQ] If the x86 people could do something about this...

[Bernd Schmidt]

> 
> If the constant in question has a high enough cost, then GCC will
> put it in a register, otherwise it just uses the constant.
> 
> I do note that the x86 CONST_COSTS basically claims that all compile
> time integer constants have the same cost (1) -- I don't know how
> accurate that is.  Someone that knows more about the x86 would have
> to comment.

That is correct. Small constants make for smaller code, but that doesn't
affect performance on the recent CPUs (apart from code cache issues).
You don't want to load constants in registers before register allocation
on the x86, since that would increase register pressure too much. However,
after reload, it would be a win to do cse on some commonly used constants
and memory locations.

The Intel patches in pgcc do that; they call it "riscifying" instructions.
They can change

addl %eax,16(%esp)

into

movl 16(%esp),%edx
addl %eax,%edx
movl %edx,16(%esp)

if edx is free. They can do that for multiple instructions, so that values
in registers get reused instead of memory locations (or constants). They
also change code like

movl $0,(%esp)
movl $0,4(%esp)
into

xorl %edx,%edx
movl %edx,(%esp)
movl %edx,4(%esp)

The point is that the Pentium can't parallelize the complex instructions
very well. Both the load-modify-write instruction and the three-instruction
sequence take three clock cycles, but it is possible that the first and
last instruction in the three-insn sequence get executed in parallel with
others. Instruction scheduling can help to increase the benefit.

Bernd

Re: [REQ] If the x86 people could do something about this...

[Jeffrey A Law]

  In message <Pine.GSO.3.96.970820171941.15112A-100000@rigel.oac.uci.edu>you wr
ite:
  > 
  >         The problem I have with gcc's code generation for i386+
  >         regards the assigning of constants to variables in
  >         memory.  This constructor just sets a lot of things to 0.
  >         The assembly output of this constructor is a bit
  >         disappointing, though.  
However, generally this only helps initialization code, not inner loops.

If the constant in question has a high enough cost, then GCC will
put it in a register, otherwise it just uses the constant.

I do note that the x86 CONST_COSTS basically claims that all compile
time integer constants have the same cost (1) -- I don't know how
accurate that is.  Someone that knows more about the x86 would have
to comment.

I believe the usual cutoff for forcing a constant into a register
is a cost of more than 2.


Of course, by increasing the cost to some value above this threshhold,
you may increase register pressure and end up with overall worse code.

It may be worth experimenting with.  The x86 gurus might be able to
provide some additional info.

One thing I did for the mn10x00 ports was to scan the insns for the
function, computing the savings that would be realized by placing the
value zero into a register vs the cost of saving and restoring the
"zero" register in the prologue.  Whichever was more efficient was
choosen.  Of course if no registers were available on a global
basis this optimization wasn't performed.

Conceptually, this can be expanded to other targets and other
compile time constants.

Jeff

[REQ] If the x86 people could do something about this...

[John Beppu]

        The problem I have with gcc's code generation for i386+
        regards the assigning of constants to variables in
        memory.  This constructor just sets a lot of things to 0.
        The assembly output of this constructor is a bit
        disappointing, though.  

.. C++ .................................................................

TextFile::TextFile()
{
    origBUF = NULL;
    lineDefLUT = NULL;
    eolnTYPE = EOLN_UNIX;
    accessMODE = xx_ACCESS;
    currentLINE = 0;
    lineQTY = 0;
    name[0] = 0;
    eolnStr[0] = 0x0d;
    eolnStr[1] = 0x0a;
    eolnStr[2] = 0x00;
    eolnStr[3] = 0x00;
}

        The following asm output was derived by using 
        
        "-O3 -fomit-frame-pointer -m486".  
        
        I would love it if gcc would be so kind as to put $0
        into a register.  The only way I found to coax gcc into
        putting $0 into a register was to compile without
        optimizations, and declare a variable of the form:

        register int blah = 0;

        Apparently the keyword "register" is ignored when
        compiling with -On (where n > 0).

.. x86 Assembly ........................................................

	.size	 _._8TextFile,.Lfe4-_._8TextFile
	.align 16
.globl __8TextFile
	.type	 __8TextFile,@function
__8TextFile:
	movl 4(%esp),%eax       ; movl $0,%ecx would be nice
	movl $0,16(%eax)        ; movl %ecx,16(%eax)
	movl $0,20(%eax)        ; movl %ecx,20(%eax)
	movl $0,156(%eax)       ; etc...
	movl $0,(%eax)
	movl $0,8(%eax)
	movl $0,4(%eax)
	movb $0,24(%eax)
	movb $13,152(%eax)
	movb $10,153(%eax)
	movb $0,154(%eax)
	movb $0,155(%eax)
	ret

        If this has already been dealt with in pgcc, great.  If
        not, I would really appreciate it if this were
        considered for modification.  It's such an easy
        optimization.  The example constructor would easily be
        twice as fast if not more if a register were to contain
        the constant $0, and used for the memory stores.

        Although this would require the use of one more register
        in a sparse register set, I believe this would be
        beneficial in more cases than detrimental.



  Thanks :)

  beppu@uci.edu .............................................................