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]
Other format: [Raw text]

Re: Honnor ix86_accumulate_outgoing_args again


On 13-10-02 6:45 PM, Jan Hubicka wrote:
So I thing we ought to honnor accumulate-outgoing-args again and in fact
consider disabling it for generic - it is disabled for core (that may need
re-benchmarking). For all AMD targets it is currently on.  I tested disabling
it on buldozer 32bit and it seems mostly SPEC neutral for specint2000 (I am
wating for more benchmarks) with very nice code size improvements in all
benchmarks with exception of MCF with LTO (not sure at all why), with overall
reduction of 5.2% (same gain as we get for -flto aproximately)
http://gcc.opensuse.org/SPEC/CINT/sb-megrez-head-64-32o-32bit/size.html
Specint 2000/2006 seems quite good. (though for spec2k6 the differences in sizes
are no longer anywhere near to -flto code size reductions)

Unfortunately there is 40% regression on mgrid with -flto (and also noticeable
regression without LTO).  First thing I noticed is that we stop omitting frame
pointer in the hottest function.  This is because we see:

(set (reg/f:SI 7 sp)
     (plus:SI (reg/f:SI 7 sp)
         (const_int -8 [0xfffffffffffffff8])))

and we end up marking SP as as uneliminable in:

           /* See if this is setting the replacement hard register for
              an elimination.

              If DEST is the hard frame pointer, we do nothing because
              we assume that all assignments to the frame pointer are
              for non-local gotos and are being done at a time when
              they are valid and do not disturb anything else.  Some
              machines want to eliminate a fake argument pointer (or
              even a fake frame pointer) with either the real frame
              pointer or the stack pointer.  Assignments to the hard
              frame pointer must not prevent this elimination.  */

           for (ep = reg_eliminate;
                ep < &reg_eliminate[NUM_ELIMINABLE_REGS];
                ep++)
             if (ep->to_rtx == SET_DEST (x)
                 && SET_DEST (x) != hard_frame_pointer_rtx
                 && (! (SUPPORTS_STACK_ALIGNMENT && stack_realign_fp
                        && REGNO (ep->to_rtx) == STACK_POINTER_REGNUM)
                     || GET_CODE (SET_SRC (x)) != PLUS
                     || XEXP (SET_SRC (x), 0) != SET_DEST (x)
                     || ! CONST_INT_P (XEXP (SET_SRC (x), 1))))
               setup_can_eliminate (ep, false);

It is because of

                 && (! (SUPPORTS_STACK_ALIGNMENT && stack_realign_fp
                        && REGNO (ep->to_rtx) == STACK_POINTER_REGNUM)

I am somewhat confused why do we need to stop eliminating.  Function is not
marked as needing drap (and in that case stack_realign_fp would be true)
What is this conditional shooting for?
This part was added to fix

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57018

and because LRA still misses some reload functionality for elimination. I am a bit embarrassed: I have this thing to do for 4 months and I still did not start to work on it yet. There are too much things on my plate.

As we are going to use outgoing arg accumulation, this problem is becoming higher priority one.


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