[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