Sub-word comparisons

[Tom Rodriguez]

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

tom