Re: [PATCH v4] SH FDPIC backend support
On Sun, 2015-11-15 at 15:39 -0500, Rich Felker wrote: > > This is basically the same as above ... it's not possible to > > conditionally construct/modify pattern descriptions in the .md. > > However, it's possible to modify the CALL_INSN_FUNCTION_USAGE > > field of > > call insns -- for some examples see 'grep -r > > CALL_INSN_FUNCTION_USAGE > > gcc/config/*'. Also, it seems the SH backend doesn't make use of > > some > > existing libcall related parameters and target hooks/macros. Maybe > > those could be helpful. > > I'll take a look at this. Let me know if you turn up anything > interesting. I'm currently working on other things, sorry. > > > > Maybe TARGET_USE_PSEUDO_PIC_REG could be useful? > > Yes. Is there any documentation on using it? I came across that but > couldn't figure out how it compares to just doing the pseudo yourself > in the target files. Is non-target-specific code affected by this? Yes, non-target-specific code seems to be affected by this in some way, although I don't know any details. Due to lack of documentation you'll have to grep yourself through it by looking for "USE_PSEUDO_PIC_REG" and "use_pseudo_pic_reg" to find the places where it's used. Cheers, Oleg
Re: [PATCH v4] SH FDPIC backend support
On Sun, Nov 15, 2015 at 02:08:34PM +0900, Oleg Endo wrote: > On Wed, 2015-11-11 at 09:56 -0500, Rich Felker wrote: > > > Sorry, I don't really understand RTL well enough to make a code > > snippet. What I want to express is that an insn "uses" (in the (use > > ...) sense) a register (r12) conditionally depending on a runtime > > option (TARGET_FDPIC). > > As far as I know this is not possible. It would require two variants > of the same pattern, one with the use and another without the use. OK. That's exactly what we've got now. > > Is this possible in the sh backend or does it need changes to > > higher-level gcc code? (i.e. is it presently possible to make an insn > > that conditionally clobbers different things rather than having to > > make tons of different insns for each possible set of clobbers?) > > This is basically the same as above ... it's not possible to > conditionally construct/modify pattern descriptions in the .md. > However, it's possible to modify the CALL_INSN_FUNCTION_USAGE field of > call insns -- for some examples see 'grep -r CALL_INSN_FUNCTION_USAGE > gcc/config/*'. Also, it seems the SH backend doesn't make use of some > existing libcall related parameters and target hooks/macros. Maybe > those could be helpful. I'll take a look at this. Let me know if you turn up anything interesting. > > Another issue I've started looking at is how r12 is put in > > fixed_regs, which is conceptually wrong. Preliminary tests show that > > removing it from fixed_regs doesn't break and produces much better > > code -- r12 gets used as a temp register in functions that don't need > > it, and in one function that made multiple calls, the saving of > > initial r12 to a call-saved register even happened in the delay slot > > of the call. I've been discussing it with Alexander Monakov on IRC > > (#musl) and based on my understanding so far of how gcc works (which > > admittedly may be wrong) the current FDPIC code looks like it's > > written not to depend on r12 being 'fixed'. Also I think I'm pretty > > close to understanding how we could make the same improvements for > > non-FDPIC PIC codegen: instead loading r12 in the prologue, load a > > pseudo, then use that pseudo for GOT access and force it into r12 the > > same way FDPIC call code does for PLT calls. Does this sound correct? > > Maybe TARGET_USE_PSEUDO_PIC_REG could be useful? Yes. Is there any documentation on using it? I came across that but couldn't figure out how it compares to just doing the pseudo yourself in the target files. Is non-target-specific code affected by this? Rich
Re: [PATCH v4] SH FDPIC backend support
On Wed, 2015-11-11 at 09:56 -0500, Rich Felker wrote: > Sorry, I don't really understand RTL well enough to make a code > snippet. What I want to express is that an insn "uses" (in the (use > ...) sense) a register (r12) conditionally depending on a runtime > option (TARGET_FDPIC). As far as I know this is not possible. It would require two variants of the same pattern, one with the use and another without the use. > Is this possible in the sh backend or does it need changes to > higher-level gcc code? (i.e. is it presently possible to make an insn > that conditionally clobbers different things rather than having to > make tons of different insns for each possible set of clobbers?) This is basically the same as above ... it's not possible to conditionally construct/modify pattern descriptions in the .md. However, it's possible to modify the CALL_INSN_FUNCTION_USAGE field of call insns -- for some examples see 'grep -r CALL_INSN_FUNCTION_USAGE gcc/config/*'. Also, it seems the SH backend doesn't make use of some existing libcall related parameters and target hooks/macros. Maybe those could be helpful. > Another issue I've started looking at is how r12 is put in > fixed_regs, which is conceptually wrong. Preliminary tests show that > removing it from fixed_regs doesn't break and produces much better > code -- r12 gets used as a temp register in functions that don't need > it, and in one function that made multiple calls, the saving of > initial r12 to a call-saved register even happened in the delay slot > of the call. I've been discussing it with Alexander Monakov on IRC > (#musl) and based on my understanding so far of how gcc works (which > admittedly may be wrong) the current FDPIC code looks like it's > written not to depend on r12 being 'fixed'. Also I think I'm pretty > close to understanding how we could make the same improvements for > non-FDPIC PIC codegen: instead loading r12 in the prologue, load a > pseudo, then use that pseudo for GOT access and force it into r12 the > same way FDPIC call code does for PLT calls. Does this sound correct? Maybe TARGET_USE_PSEUDO_PIC_REG could be useful? Cheers, Oleg
Re: [PATCH v4] SH FDPIC backend support
On Wed, Nov 11, 2015 at 09:56:42AM -0500, Rich Felker wrote: > > > 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)? > > I suspect it makes very little difference, but to compare I'd need to > do the same hack on 5.2.0 or trunk. The only difference should be one > additional load per call, and one additional GOT slot per function > called this way (but just once per executable/library). Actually I think this is not quite right: if the call takes place via the GOT, this also requires the initial r12 to be preserved somewhere in order to load the function address, whereas for SFUNC_STATIC, the initial r12 can be completely discarded, right? (SFUNC functions are not permitted to use the GOT themselves as far as I can tell, and thus do not receive the hidden GOT argument in r12.) Rich
Re: [PATCH v4] SH FDPIC backend support
On Wed, Nov 11, 2015 at 11:36:26PM +0900, Oleg Endo wrote: > 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? Sorry, I don't really understand RTL well enough to make a code snippet. What I want to express is that an insn "uses" (in the (use ...) sense) a register (r12) conditionally depending on a runtime option (TARGET_FDPIC). > > 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. Yes, I see that. What I was really wondering though is why the new call site generation code and constraint was added when the call_pcrel code already has mechanisms for this, rather than just duplicating the internals that call_pcrel uses. It seems like we're doing things in a gratuitously different way here. > 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. Is this possible in the sh backend or does it need changes to higher-level gcc code? (i.e. is it presently possible to make an insn that conditionally clobbers different things rather than having to make tons of different insns for each possible set of clobbers?) > > 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)? I suspect it makes very little difference, but to compare I'd need to do the same hack on 5.2.0 or trunk. The only difference should be one additional load per call, and one additional GOT slot per function called this way (but just once per executable/library). Another issue I've started looking at is how r12 is put in fixed_regs, which is conceptually wrong. Preliminary tests show that removing it from fixed_regs doesn't break and produces much better code -- r12 gets used as a temp register in functions that don't need it, and in one function that made multiple calls, the saving of initial r12 to a call-saved register even happened in the delay slot of the call. I've been discussing it with Alexander Monakov on IRC (#musl) and based on my understanding so far of how gcc works (which admittedly may be wrong) the current FDPIC code looks like it's written not to depend on r12 being 'fixed'. Also I think I'm pretty close to understanding how we could make the same improvements for non-FDPIC PIC codegen: instead of loading r12 in the prologue, load a pseudo, then use that pseudo for GOT access and force it into r12 the same way FDPIC call code does for PLT calls. Does this sound correct? Rich
Re: [PATCH v4] SH FDPIC backend support
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
Re: [PATCH v4] SH FDPIC backend support
On Tue, Oct 27, 2015 at 11:01:39PM +0900, Oleg Endo wrote: > On Mon, 2015-10-26 at 22:47 -0400, Rich Felker wrote: > > On Sun, Oct 25, 2015 at 11:28:51PM +0900, Oleg Endo wrote: > > > On Fri, 2015-10-23 at 02:32 -0400, Rich Felker wrote: > > > > Here's my updated version of the FDPIC patch with all requested > > > > changes made and Changelog added. I've included all the original > > > > authors. This is my first time writing such an extensive > > > > Changelog > > > > entry so please let me know if there are things I got wrong. > > > > > > I took the liberty and fixed some minor formatting trivia and > > > extracted > > > functions sh_emit_storesi and sh_emit_storehi which are used in > > > sh_trampoline_init to effectively memcpy code into the trampoline > > > area. Can you please check it? If it's OK I'll commit the > > > attached > > > patch to trunk. > > > > Is there anything in particular you'd like me to check? It builds > > fine > > for fdpic target, successfully compiles musl libc.so, and busybox > > runs > > with the resulting libc.so. I did a quick visual inspection of the > > diff between my version and yours too and didn't see anything that > > looked suspicious to me. > > Thanks. I have committed it as r229438 after a sanity check with "make > all" on sh-elf. > > 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? 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. 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. Rich
Re: [PATCH v4] SH FDPIC backend support
On Mon, 2015-10-26 at 22:47 -0400, Rich Felker wrote: > On Sun, Oct 25, 2015 at 11:28:51PM +0900, Oleg Endo wrote: > > On Fri, 2015-10-23 at 02:32 -0400, Rich Felker wrote: > > > Here's my updated version of the FDPIC patch with all requested > > > changes made and Changelog added. I've included all the original > > > authors. This is my first time writing such an extensive > > > Changelog > > > entry so please let me know if there are things I got wrong. > > > > I took the liberty and fixed some minor formatting trivia and > > extracted > > functions sh_emit_storesi and sh_emit_storehi which are used in > > sh_trampoline_init to effectively memcpy code into the trampoline > > area. Can you please check it? If it's OK I'll commit the > > attached > > patch to trunk. > > Is there anything in particular you'd like me to check? It builds > fine > for fdpic target, successfully compiles musl libc.so, and busybox > runs > with the resulting libc.so. I did a quick visual inspection of the > diff between my version and yours too and didn't see anything that > looked suspicious to me. Thanks. I have committed it as r229438 after a sanity check with "make all" on sh-elf. 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... Cheers, Oleg
Re: [PATCH v4] SH FDPIC backend support
On Sun, Oct 25, 2015 at 11:28:51PM +0900, Oleg Endo wrote: > On Fri, 2015-10-23 at 02:32 -0400, Rich Felker wrote: > > Here's my updated version of the FDPIC patch with all requested > > changes made and Changelog added. I've included all the original > > authors. This is my first time writing such an extensive Changelog > > entry so please let me know if there are things I got wrong. > > I took the liberty and fixed some minor formatting trivia and extracted > functions sh_emit_storesi and sh_emit_storehi which are used in > sh_trampoline_init to effectively memcpy code into the trampoline > area. Can you please check it? If it's OK I'll commit the attached > patch to trunk. Is there anything in particular you'd like me to check? It builds fine for fdpic target, successfully compiles musl libc.so, and busybox runs with the resulting libc.so. I did a quick visual inspection of the diff between my version and yours too and didn't see anything that looked suspicious to me. Rich
Re: [PATCH v4] SH FDPIC backend support
On Fri, 2015-10-23 at 02:32 -0400, Rich Felker wrote:
> Here's my updated version of the FDPIC patch with all requested
> changes made and Changelog added. I've included all the original
> authors. This is my first time writing such an extensive Changelog
> entry so please let me know if there are things I got wrong.
I took the liberty and fixed some minor formatting trivia and extracted
functions sh_emit_storesi and sh_emit_storehi which are used in
sh_trampoline_init to effectively memcpy code into the trampoline
area. Can you please check it? If it's OK I'll commit the attached
patch to trunk.
Cheers,
OlegIndex: gcc/config/sh/constraints.md
===
--- gcc/config/sh/constraints.md (revision 229290)
+++ gcc/config/sh/constraints.md (working copy)
@@ -25,6 +25,7 @@
;; Bsc: SCRATCH - for the scratch register in movsi_ie in the
;; fldi0 / fldi0 cases
;; Cxx: Constants other than only CONST_INT
+;; Ccl: call site label
;; Css: signed 16-bit constant, literal or symbolic
;; Csu: unsigned 16-bit constant, literal or symbolic
;; Csy: label or symbol
@@ -233,6 +234,11 @@
hence mova is being used, hence do not select this pattern."
(match_code "scratch"))
+(define_constraint "Ccl"
+ "A call site label, for bsrf."
+ (and (match_code "unspec")
+ (match_test "XINT (op, 1) == UNSPEC_CALLER")))
+
(define_constraint "Css"
"A signed 16-bit constant, literal or symbolic."
(and (match_code "const")
Index: gcc/config/sh/linux.h
===
--- gcc/config/sh/linux.h (revision 229290)
+++ gcc/config/sh/linux.h (working copy)
@@ -67,7 +67,8 @@
#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
#undef SUBTARGET_LINK_EMUL_SUFFIX
-#define SUBTARGET_LINK_EMUL_SUFFIX "_linux"
+#define SUBTARGET_LINK_EMUL_SUFFIX "%{mfdpic:_fd;:_linux}"
+
#undef SUBTARGET_LINK_SPEC
#define SUBTARGET_LINK_SPEC \
"%{shared:-shared} \
Index: gcc/config/sh/sh-c.c
===
--- gcc/config/sh/sh-c.c (revision 229290)
+++ gcc/config/sh/sh-c.c (working copy)
@@ -137,6 +137,11 @@
builtin_define ("__HITACHI__");
if (TARGET_FMOVD)
builtin_define ("__FMOVD_ENABLED__");
+ if (TARGET_FDPIC)
+{
+ builtin_define ("__SH_FDPIC__");
+ builtin_define ("__FDPIC__");
+}
builtin_define (TARGET_LITTLE_ENDIAN
? "__LITTLE_ENDIAN__" : "__BIG_ENDIAN__");
Index: gcc/config/sh/sh-mem.cc
===
--- gcc/config/sh/sh-mem.cc (revision 229290)
+++ gcc/config/sh/sh-mem.cc (working copy)
@@ -108,29 +108,30 @@
rtx r4 = gen_rtx_REG (SImode, 4);
rtx r5 = gen_rtx_REG (SImode, 5);
- function_symbol (func_addr_rtx, "__movmemSI12_i4", SFUNC_STATIC);
+ rtx lab = function_symbol (func_addr_rtx, "__movmemSI12_i4",
+ SFUNC_STATIC).lab;
force_into (XEXP (operands[0], 0), r4);
force_into (XEXP (operands[1], 0), r5);
- emit_insn (gen_block_move_real_i4 (func_addr_rtx));
+ emit_insn (gen_block_move_real_i4 (func_addr_rtx, lab));
return true;
}
else if (! optimize_size)
{
- const char *entry_name;
rtx func_addr_rtx = gen_reg_rtx (Pmode);
- int dwords;
rtx r4 = gen_rtx_REG (SImode, 4);
rtx r5 = gen_rtx_REG (SImode, 5);
rtx r6 = gen_rtx_REG (SImode, 6);
- entry_name = (bytes & 4 ? "__movmem_i4_odd" : "__movmem_i4_even");
- function_symbol (func_addr_rtx, entry_name, SFUNC_STATIC);
+ rtx lab = function_symbol (func_addr_rtx, bytes & 4
+ ? "__movmem_i4_odd"
+ : "__movmem_i4_even",
+ SFUNC_STATIC).lab;
force_into (XEXP (operands[0], 0), r4);
force_into (XEXP (operands[1], 0), r5);
- dwords = bytes >> 3;
+ int dwords = bytes >> 3;
emit_insn (gen_move_insn (r6, GEN_INT (dwords - 1)));
- emit_insn (gen_block_lump_real_i4 (func_addr_rtx));
+ emit_insn (gen_block_lump_real_i4 (func_addr_rtx, lab));
return true;
}
else
@@ -144,10 +145,10 @@
rtx r5 = gen_rtx_REG (SImode, 5);
sprintf (entry, "__movmemSI%d", bytes);
- function_symbol (func_addr_rtx, entry, SFUNC_STATIC);
+ rtx lab = function_symbol (func_addr_rtx, entry, SFUNC_STATIC).lab;
force_into (XEXP (operands[0], 0), r4);
force_into (XEXP (operands[1], 0), r5);
- emit_insn (gen_block_move_real (func_addr_rtx));
+ emit_insn (gen_block_move_real (func_addr_rtx, lab));
return true;
}
@@ -161,7 +162,7 @@
rtx r5 = gen_rtx_REG (SImode, 5);
rtx r6 = gen_rtx_REG (SImode, 6);
- function_symbol (func_addr_rtx, "__movmem", SFUNC_STATIC);
+ rtx lab = function_symbol (func_addr_rtx, "__movmem", SFUNC_STATIC).lab;
force_into (XEXP (operands[0], 0), r4);
force_into (XEXP (operands[1], 0), r5);
@@ -174,7 +175,7 @@
final_switch = 16 - ((bytes / 4) % 16);
while_loop = ((bytes / 4) / 16 - 1) * 16;
[PATCH v4] SH FDPIC backend support
Here's my updated version of the FDPIC patch with all requested changes made and Changelog added. I've included all the original authors. This is my first time writing such an extensive Changelog entry so please let me know if there are things I got wrong. Rich 2010-08-19 Daniel Jacobowitz Joseph Myers Mark Shinwell Andrew Stubbs Rich Felker gcc/ * config.gcc: Handle --enable-fdpic. * config/sh/constraints.md: Add Ccl constraint. * config/sh/linux.h (SUBTARGET_LINK_EMUL_SUFFIX): Handle -mfdpic. * config/sh/sh-c.c: (sh_cpu_cpp_builtins): Add __FDPIC__ and __SH_FDPIC__. * config/sh/sh-mem.cc (expand_block_move): Support FDPIC for calls to library functions. * config/sh/sh-protos.h (function_symbol): Adapt for FDPIC support. (sh_get_fdpic_reg_initial_val, sh_load_function_descriptor): Add functions for FDPIC support. * config/sh/sh.c (sh_assemble_integer, sh_cannot_force_const_mem_p, sh_reloc_rw_mask, TARGET_ASM_INTEGER, TARGET_CANNOT_FORCE_CONST_MEM, TARGET_ASM_RELOC_RW_MASK): New for FDPIC. (sh_option_override): Force -fPIC and -fno-function-cse for FDPIC. (sh_asm_output_addr_const_extra): Add function descriptor reference outputs. (prepare_move_operands): Use FDPIC initial GOT register for TLS-related GOT access; inhibit cross-section address offset constants for FDPIC. (sh_assemble_integer): Produce function descriptor addresses for FDPIC function address values. (sh_cannot_copy_insn_p): Inhibit copying instructions that are FDPIC PC-relative call sites. (expand_ashiftrt): Support FDPIC for call to library function. (sh_expand_prologue): Inhibit PC-relative GOT address load for FDPIC; for FDPIC, GOT address is a hidden argument in r12. (nonpic_symbol_mentioned_p): Add cases for UNSPEC_GOTFUNCDESC and UNSPEC_GOTOFFFUNCDESC. (legitimize_pic_address): Resolve function symbols to function descriptors for FDPIC; do not use GOT-relative addressing for local data that may be read-only on FDPIC. (sh_trampoline_init): Generate FDPIC trampolines. (sh_expand_sym_label2reg): Don't assume sibcalls are local; this need not be true for FDPIC. (sh_output_mi_thunk): Generate FDPIC call. (function_symbol): For SFUNC_STATIC on FDPIC, use PC-relative addressing rather than GOT-relative addressing; generate call site labels to make this possible. (sh_conditional_register_usage): Mark GOT register usage by FDPIC. (sh_legitimate_constant_p): Impose FDPIC constant constraints. (sh_cannot_force_const_mem_p, sh_load_function_descriptor, sh_get_fdpic_reg_initial_val, sh_reloc_rw_mask): New for FDPIC. * config/sh/sh.h (SUBTARGET_ASM_SPEC, SUBTARGET_LINK_EMUL_SUFFIX): Handle -mfdpic. (FDPIC_SELF_SPECS): New self specs to insert -mfdpic by default if configured with --enable-fdpic. (TRAMPOLINE_SIZE): Select trampoline size for FDPIC. (PIC_OFFSET_TABLE_REG_CALL_CLOBBERED, SH_OFFSETS_MUST_BE_WITHIN_SECTIONS_P): New for FDPIC. (ASM_PREFERRED_EH_DATA_FORMAT): Add EH format constraints for FDPIC. * config/sh/sh.md (R12_REG, UNSPEC_GOTFUNCDESC, UNSPEC_GOTOFFFUNCDESC, calli_fdpic, call_valuei_fdpic, sibcalli_fdpic, sibcalli_pcrel_fdpic, sibcall_pcrel_fdpic, sibcall_valuei_fdpic, sibcall_valuei_pcrel_fdpic, sibcall_value_pcrel_fdpic, sym2GOTFUNCDESC, symGOTFUNCDESC2reg, sym2GOTOFFFUNCDESC, symGOTOFFFUNCDESC2reg): New. (udivsi3_i1, udivsi3_i4, udivsi3_i4_single, udivsi3, divsi_inv_call_combine, divsi3_i4, divsi3_i4_single, divsi3, ashlsi3, ashlsi3_d_call, ashrsi3_n, lshrsi3, lshrsi3_d_call, calli, call_valuei, call, call_value, sibcalli, sibcalli_pcrel, sibcall_pcrel, sibcall, sibcall_valuei, sibcall_valuei_pcrel, sibcall_value_pcrel, sibcall_value, GOTaddr2picreg, symGOT_load, symGOTOFF2reg, block_move_real, block_lump_real, block_move_real_i4, block_lump_real_i4): Add support for FDPIC. (mulsi3, ic_invalidate_line, initialize_trampoline, call_pop, call_value_pop): Adjust for new function_symbol signature. * config/sh/sh.opt (-mfdpic): New option. * doc/install.texi (Options specification): Add --enable-fdpic. * doc/invoke.texi (SH Options): Add -mfdpic. include/ * longlong.h (udiv_qrnnd): Add FDPIC compatible version. libitm/ * config/sh/sjlj.S (_ITM_beginTransaction): Bypass PLT calling GTM_begin_transaction for compatibility with FDPIC. diff --git a/gcc/config.gcc b/gcc/config.gcc index bf26776..ed118f3 100644 --- a/gcc/co
