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
