On MIPS, PIC calls are indirect calls that need to be dispatched via an ABI
mandated register. At expansion time we load the symbol into a pseudo then
expand the call. There is a linker optimization that can turn these indirect
calls into direct calls under some circumstances. This can improve branch
prediction (the real ABI requirement is that the PIC register is live on entry
to the callee). To assist the linker we need to annotate the indirect call
with the function symbol.
Since the call is expanded early, during the various optimizations the meaning
of the call can change to no longer refer to the original function. E.g.:
f (int i, int j)
{
while (i--)
if (j)
g ();
else
h ();
}
You would hope that GCC would move the condition out of the loop and preset
the PIC register accordingly with only the indirect call in the loop body.
(No, this does not happen ATM.)
I've however seen this happening with cross-jumping.
AFAICT we have two options. We either create a simple (local) dataflow in
md_reorg and annotate the calls with the result or set MEM_EXPR of the mem
inside the call to the function decl during expansion.
I have a patch for the latter (I used to do the former in our GCC). It seems
to me that this perfectly fits with the definition of MEM_EXPR but I don't
think MEM_EXPR is ever used for mems inside calls. In fact, I don't think any
of the MEM_ATTRS are meaningful in a call expression.
What's promising that cross-jumping treats them correctly. As it merges
MEM_ATTRS it clears mismatching MEM_EXPRs no matter where the mem expression
is found in the insn. And my patch bootstraps successfully.
So, is using MEM_EXPR for this a bad idea?
Adam
