tom.rodriguez at oracle.com
Thu Nov 3 19:58:58 UTC 2016
> On Nov 3, 2016, at 12:51 PM, Doug Simon <doug.simon at oracle.com> wrote:
>> On 3 Nov 2016, at 20:24, Andrew Haley <aph at redhat.com> wrote:
>> On 03/11/16 19:18, Doug Simon wrote:
>>> The lowering of a CompareNode to a CompareOp is AArch64 specific as
>>> far as I can see. This originates from the AArch64 implementations
>>> of LIRGenerator.emitCompareBranch and
>>> LIRGenerator.emitConditionalMove. You’ll have to change those
>>> methods to generate LIR ops that AArch64 actually supports.
>> Oh sure, I can do that, but that wasn't my problem, it was how to stop
>> Graal from creating sub-word comparisons in the first place. Such
>> operations aren't part of the JVM at all, but are generated when the
>> bytecode is canonicalized. I can generate code for sub-word
>> comparisons, but it won't be good code. AArch64 is designed to work
>> well for languages like C and Java, which don't have any arithmetic
>> operations on sub-word types.
> I’m not sure where (or if) Graal generates sub-word comparisons nowadays so am not sure where we’d have to add a capability check. Have you seen it occur? I’ve just run all our unit tests as well as a bootstrap and never saw it occur.
I believe they can fall out of other transformations like the stripping of conversions, like Compare(ZeroExtend(x), ZeroExtend(y)) -> Compare(x, y). I suspect the way this is supposed to work is that the if your backend doesn’t really support sub word types then it should never produce them. So even if x is an i8 at the Node level the LIR operation should produce a word in the platform kind. And LIR generation should be driven by the LIR types, not by the types in the HIR. I suspect that AArch64 is just slightly out of date with that change.
More information about the graal-dev