This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH v4] SH FDPIC backend support
- From: Oleg Endo <oleg dot endo at t-online dot de>
- To: Rich Felker <dalias at libc dot org>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 11 Nov 2015 23:36:26 +0900
- Subject: Re: [PATCH v4] SH FDPIC backend support
- Authentication-results: sourceware.org; auth=none
- References: <20151021034138 dot GA4087 at brightrain dot aerifal dot cx> <1445433471 dot 5521 dot 100 dot camel at t-online dot de> <20151021201510 dot GV8645 at brightrain dot aerifal dot cx> <20151023063221 dot GI8645 at brightrain dot aerifal dot cx> <1445783331 dot 8060 dot 3 dot camel at t-online dot de> <20151027024706 dot GU8645 at brightrain dot aerifal dot cx> <1445954499 dot 8060 dot 22 dot camel at t-online dot de> <20151110200700 dot GT3818 at brightrain dot aerifal dot cx>
On Tue, 2015-11-10 at 15:07 -0500, Rich Felker wrote:
> > The way libcalls are now emitted is a bit unhandy. If more special
> > -ABI
> > libcalls are to be added in the future, they all have to do the jsr
> > vs.
> > bsrf handling (some potential candidates for new libcalls are
> > optimized
> > soft FP routines). Then we still have PR 65374 and PR 54019. In
> > the
> > future maybe we should come up with something that allows emitting
> > libcalls in a more transparent way...
>
> I'd like to look into improving this at some point in the near
> future.
> On further reading of the changes made, I think there's a lot of code
> we could reduce or simplify.
>
> In all the places where new RTL patterns were added for *call*_fdpic,
> the main constraint change vs the non-fdpic version is using REG_PIC.
> Is it possible to make a REG_GOT_ARG macro or similar that's defined
> as something like TARGET_FDPIC ? REG_PIC : nonexistent_or_dummy?
I'm not sure I understand what you mean by that. Do you have a small
code snippet example?
> As for the call site stuff, I wonder why the existing call site stuff
> used by "call_pcrel" can't be used for SFUNC_STATIC.
"call_pcrel" is a real call insn. The libcalls are not expanded as
real call insns to avoid the regular register save/restores etc which
is needed to do a normal function call.
I guess the generic fix for this issue would be some mechanism to
specify which regs are clobbered/preserved and then provide the right
settings for the libcall functions.
> I'm actually
> trying to prepare a simpler FDPIC patch for other gcc versions we're
> interested in that's not so invasive, and for now I'm just having
> function_symbol replace SFUNC_STATIC with SFUNC_GOT on TARGET_FDPIC
> to
> avoid needing all the label stuff, but it would be nice to find a way
> to reuse the existing framework.
Do you know how this affects code size (and inherently performance)?
Cheers,
Oleg