This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Honnor ix86_accumulate_outgoing_args again
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Uros Bizjak <ubizjak at gmail dot com>, Richard Henderson <rth at redhat dot com>, Ganesh dot Gopalasubramanian at amd dot com, Vladimir Makarov <vmakarov at redhat dot com>
- Date: Wed, 2 Oct 2013 15:50:58 -0700
- Subject: Re: Honnor ix86_accumulate_outgoing_args again
- Authentication-results: sourceware.org; auth=none
- References: <20131002173249 dot GB12304 at kam dot mff dot cuni dot cz> <20131002224516 dot GA26046 at kam dot mff dot cuni dot cz>
On Wed, Oct 2, 2013 at 3:45 PM, Jan Hubicka <hubicka@ucw.cz> 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:
Does it happen with both 32-bit and 64-bit?
> (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 < ®_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?
Why is stack_realign_fp true?
--
H.J.