[aarch64-port-dev ] Whether or not to revert of checkcast_arraycopy stub to generate return value expected by generic C2 code
Andrew Haley
aph at redhat.com
Tue Oct 15 07:36:47 PDT 2013
On 10/15/2013 03:12 PM, Andrew Dinn wrote:
> The AArch64 checkcast_arraycopy stub has been implemented to employ a
> different semantics for the return value to that employed by x86 and
> this is running afoul of the expectations built into the generis layer
> of C2.
>
> Specifically, on x86 the return value is
>
> 0 : if all values were copied
> -1^K : if a partial copy of K values occurred -- equivalently, -(k+1)
>
> On aarch64 the return value is
>
> 0 : if all values were copied
> K : if there are K values uncopied
>
> (yes that first rule is really redundant)
>
> The problem is that the generic code in the C2 compiler implements the
> stub by generating ideal code which assumes the former return value
> semantics i.e. it constructs a test node
>
> (If (Cmp res zero) cr)
>
> to test the return value and then in the false branch generates
>
> (Set copied (XorI res -1))
>
> and uses the result to feed some arithmetic nodes
>
> (SubI length copied)
> (AddI srcpos copied)
> (AddI dstpos copied)
>
> which it then passes into a runtime call
>
> (CallRuntime "OptoRuntime::slow_arraycopy_Type")
>
> So, we have two options here: revert the stub so it returns 0 or -1^K or
> edit the generic layer code to include an AArch64-specific compilation
> path which expects the semantics adopted for C1.
>
> I have implemented the changes needed to revert the behaviour of the
> stub and the diff is attached below.
There's a better solution: keep the stub as it is, but if the copy
fails return -1^K. I will make that change if you like. It's much
better than the rather nightmarish code we had before.
Andrew.
More information about the aarch64-port-dev
mailing list