[PATCH] rs6000: Support ELFv2 sibcall for indirect calls [PR96787]

Segher Boessenkool segher@kernel.crashing.org
Thu Aug 27 20:17:45 GMT 2020


On Thu, Aug 27, 2020 at 01:51:25PM -0500, Bill Schmidt wrote:
> >>+  /* For ELFv2, r12 and CTR need to hold the function address
> >>+     for an indirect call.  */
> >>+  if (GET_CODE (func_desc) != SYMBOL_REF && DEFAULT_ABI == ABI_ELFv2)
> >>+    {
> >>+      r12 = gen_rtx_REG (Pmode, 12);
> >>+      if (!rtx_equal_p (r12, func_desc))
> >>+	emit_move_insn (r12, func_desc);
> >These last two lines aren't needed?  A move from r12 to r12 is harmless,
> >and should be optimised away just fine?
> 
> On entry to this function, func_desc has the function address, and the 
> problem is for a sibcall it is generally not in r12.  So I'm forcing it 
> into r12 here.  I guess we could remove the !rtx_equal_p test and 

Yes, that is what I meant, sorry.

> generate an unnecessary copy, but I don't see why we should do that.  

Because it is simpler code.  Micro-optimisations are often not
optimisations at all, just obfuscations, and those hurt in various
ways (they make bigger binary code than necessary, but perhaps more
importantly they make bigger source code, which hurts in various ways).

It not the copy that is unnecessary: the preventing it *here*, manually,
is what is unnecessary.

> This is the same thing we do elsewhere (such as rs6000_aix_call).

That does not mean we have to do the same harmful (or just not useful)
thing everywhere else as well ;-)

> >>    /* Create the call.  */
> >>-  call[0] = gen_rtx_CALL (VOIDmode, gen_rtx_MEM (SImode, func_desc), 
> >>tlsarg);
> >>+  call[0] = gen_rtx_CALL (VOIDmode, gen_rtx_MEM (SImode, func_addr), 
> >>tlsarg);
> >I don't understand this change?  (Maybe I'm not looking well enough.)
> 
> Prior to this change, func_desc comes in as a parameter and is never 
> changed.  Now it's either that case, or it's the new case, so this just 
> is the join point of that decision.

So I'm not looking well enough, okay :-)


Segher


More information about the Gcc-patches mailing list