[SLOF] [PATCH 3/4] fbuffer: Implement MRMOVE as an accelerated primitive

[Segher Boessenkool]

On Mon, Sep 14, 2015 at 08:43:37PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2015-09-14 at 12:27 +0200, Thomas Huth wrote:
> > On 12/09/15 07:28, Benjamin Herrenschmidt wrote:
> 
> > This seems to work:
> > 
> > static unsigned long __attribute__((noinline))
> > call_c(cell arg0, cell arg1, cell arg2, cell entry)
> > {
> > 	unsigned long (*fp)(cell a0, cell a1, cell a2);
> > 	unsigned long desc[3];
> > 
> > 	desc[0] = entry.u;
> > 	desc[1] = desc[2] = 0;
> > 	barrier();
> > 	fp = (unsigned long (*)(cell a0, cell a1, cell a2))desc;
> > 
> > 	return fp(arg0, arg1, arg2);
> > }
> 
> Should we set the TOC in the descriptor to match the caller or should
> we just leave it to 0 ?

If 0 actually works (the caller sets the TOC if it needs it, like
what CALL-C was meant for, namely RTAS), that is a better choice.

If the target has the same TOC, then why are we doing these games
at all!  We could just pass the OPD address instead of the code
address.

> > But it also contains a small hack: I need the barrier() in between
> > (which is a asm volatile("":::"memory) call) or the compiler will not
> > recognize fp as being set (even though we compile with
> > -fno-strict-aliasing ?!?).
> 
> Now *that* is strange. segher any idea here ?

Nope.  Other than that casting between code and data pointers isn't
valid C, but this is GNU C instead (-std=gnu99) and it is valid there.

I'll debug it; what GCC version?

> > Do you think the above code is acceptable? If yes, I'll send a proper
> > patch for this, if not, I think I'll have a try with one of Segher's
> > suggestions.

It's not acceptable if we need the barrier, certainly not if we do not
know why!

I like the code otherwise though (but make a typedef for the function
type, it's used more than once)?


Segher