This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [PATCH] PROMOTE_FOR_CALL_ONLY on sparc


On Tue, Dec 07, 1999 at 07:44:18AM -0500, Richard Kenner wrote:
>     As SPARC does not have any arithmetic instructions which as a side effect
>     zero/sign extend the register (with the exception of SImode shift right),
>     so not defining PROMOTE_FOR_CALL_ONLY leads into suboptimal code on sparc64
>     where a sign/zero extension is used after nearly every statement.
> 
> Are you sure?  If you don't promote, then you have to zero/sign extend
> on *uses* of a variable, while if you do, you zero/sign extend on *sets*.
> Since most variables are set less than they are used, promotion usually
> wins.  Do you have any data suggesting the opposite?

It is not that strightforward, but I eyeballed a lot of code and it seemed
to help.
If PROMOTE_FOR_CALL_ONLY is set, then promotion is done on passing arguments
to the child function only, while if it is not set, after every statement
there is a promotion. Cases where you directly pass your arguments to the
child function are usually optimized away in both cases.
Example of routine which benefits from PROMOTE_FOR_CALL_ONLY:

int foo(int a, int b, int c)
{
        int d, e, f, g;
        d = a + b;
        e = b + c;
        f = c | d;
        g = e | d;
        return (d & e) + (f ^ g);
}

(I just typed in random arithmetic between local variables).
This code outputs 1 sign extension if PROMOTE_FOR_CALL_ONLY is defined
and 3 sign extensions if not.
The code for the first case looks like (.rtl output):

...
(insn 22 18 25 (set (reg/v:SI 112)
        (plus:SI (reg/v:SI 106)
            (reg/v:SI 108))) -1 (nil)
    (nil))
...

and for the latter:

...
(insn 16 12 17 (set (reg:SI 113)
        (plus:SI (subreg/s:SI (reg/v:DI 106) 0)
            (subreg/s:SI (reg/v:DI 107) 0))) -1 (nil)
    (nil))

(insn 17 16 19 (set (reg:DI 114)
        (sign_extend:DI (reg:SI 113))) -1 (nil)
    (nil))
...

Also, with PROMOTE_FOR_CALL_ONLY, random compiled code seems to be shorter
in the number of instructions. Say regclass.c compiled by stage1 has 4124
instructions if compiled with PROMOTE_FOR_CALL_ONLY and 4203 instructions if
compiled without it (in both cases with the arguments make bootstrap passes
to it).

Once sparc64 userland stabilizes a little bit, I will do proper benchmarking
with/without this define to see what is better for usual programs (will try
linux kernel, glibc, X), but until then IMHO both variants should work.
As ! PROMOTE_FOR_CALL_ONLY is widely tested on most architectures, I think
it is better now to test PROMOTE_FOR_CALL_ONLY, where I already found one
bug in cse (posted some days ago) plus am now fighting some unrolling bug.
The code output from gcse seems perfectly legal to me, so it is most
probably some loop and/or unroll bug.

Cheers,
    Jakub
___________________________________________________________________
Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj
Linux version 2.3.18 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]