This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] enable fdpic targets/emulations for sh*-*-linux*
- From: Oleg Endo <oleg dot endo at t-online dot de>
- To: Rich Felker <dalias at libc dot org>
- Cc: Segher Boessenkool <segher at kernel dot crashing dot org>, binutils at sourceware dot org
- Date: Mon, 05 Oct 2015 21:31:42 +0900
- 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> <20151005020219 dot GG8645 at brightrain dot aerifal dot cx>
On Sun, 2015-10-04 at 22:02 -0400, Rich Felker wrote:
> 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".
Please open a GCC bugzilla PR for this.