This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] enable fdpic targets/emulations for sh*-*-linux*
- From: Rich Felker <dalias at libc dot org>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: Oleg Endo <oleg dot endo at t-online dot de>, binutils at sourceware dot org
- Date: Sun, 4 Oct 2015 22:02:19 -0400
- Subject: Re: [PATCH] enable fdpic targets/emulations for sh*-*-linux*
- Authentication-results: sourceware.org; auth=none
- References: <1443627005 dot 2509 dot 189 dot camel at t-online dot de> <20150930183810 dot GE8645 at brightrain dot aerifal dot cx> <1443715139 dot 2031 dot 134 dot camel at t-online dot de> <20151001164630 dot GI8645 at brightrain dot aerifal dot cx> <1443804962 dot 2031 dot 290 dot camel at t-online dot de> <20151002175223 dot GU8645 at brightrain dot aerifal dot cx> <1443863059 dot 2031 dot 433 dot camel at t-online dot de> <20151003185947 dot GC8645 at brightrain dot aerifal dot cx> <1443929574 dot 2031 dot 506 dot camel at t-online dot de> <20151004084220 dot GA26681 at gate dot crashing dot org>
On Sun, Oct 04, 2015 at 03:42:20AM -0500, Segher Boessenkool wrote:
> On Sun, Oct 04, 2015 at 12:32:54PM +0900, Oleg Endo wrote:
> > > I think we should focus on the big performance problem that would make
> > > a much much bigger difference: very bad codegen by gcc. Aside from
> > > lack of shrink-wrapping, poor hanling of the PIC register (like the
> > > way x86 used to handle %ebx, as permanently-reserved and unusable)
> > > stands out at something that needs to be fixed.
> >
> > Shrink wrapping is being done for all backends. In fact, it has been
> > improved recently. Of course there could be some SH specific cases
> > which aren't optimized well. Please open PRs in GCC's bugzilla for
> > issues with the compiler.
>
> If the prologue sets up a register that is used pretty much everywhere
> (like a PIC register) we cannot shrink-wrap much. After shrink-wrapping
> you always still have a single prologue (and epilogue).
>
> Your problem might be different; I can't tell without examples.
Indeed, this is my concern. Shrink-wrapping cannot be effective until
all hard-coded prologue/epilogue logic (and fixed register use for GOT
registers, frame pointers, etc.) is eliminated and replaced by
representing it as proper patterns/constraints that the compiler can
manipulate. Right now we have prologue logic like "if anything in the
function uses the GOT, emit GOT register setup in the prologue".
Rich