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
