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

[Thomas Huth]

On 14/09/15 14:13, Segher Boessenkool wrote:
> 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.

Right, ... actually, that function should maybe rather have been called
"call_asm()" instead of "call_c()" to make this clear.

>>> 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?

$ powerpc64-linux-gnu-gcc --version
powerpc64-linux-gnu-gcc (GCC) 4.9.3 20150402 (Advance-Toolchain-at8.0)
[ibm/gcc-4_9-branch, revision: 221849 merged from gcc-4_9-branch,
revision 221813]

>>> 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)?

Ok, in case there is a solution to get this working without the barrier,
I can use a typedef instead for sure.

If not, I think it is maybe easiest if I move the inline assembly code
to a real .S file instead, as you suggested earlier.

 Thomas