[SLOF] [PATCH 3/4] fbuffer: Implement MRMOVE as an accelerated primitive
thuth at redhat.com
Mon Sep 14 23:40:20 AEST 2015
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;
>>> desc = entry.u;
>>> desc = desc = 0;
>>> 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
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,
>>> 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
> 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.
More information about the SLOF