Sub-word comparisons

[Roland Schatz]

On 11/04/2016 01:16 PM, Roland Schatz wrote:
> On 11/04/2016 12:46 PM, Andrew Haley wrote:
>> Ah, I just looked at SPARC, and it does the exact same thing:
>>
>>          int compareBytes = cmpKind.getSizeInBytes();
>>          // SPARC compares 32 or 64 bits
>>          if (compareBytes < left.getPlatformKind().getSizeInBytes()) {
>>              left = arithmeticLIRGen.emitSignExtend(left, 
>> compareBytes * 8, XWORD.getSizeInBytes() * 8);
>>          }
>>          if (compareBytes < right.getPlatformKind().getSizeInBytes()) {
>>              right = arithmeticLIRGen.emitSignExtend(right, 
>> compareBytes * 8, XWORD.getSizeInBytes() * 8);
>>          }
>>
>> OK, I give up.  That must be the only way to do it.
> Yes, unfortunately that's the only way to do it right now.
>
> The issue comes from the x86 backend, where doing sub-word comparisons 
> sometimes makes code faster. In hindsight, the decision to do this 
> optimization in the platform independent code was wrong. When this 
> code was written, there was only the x86 backend, and it was easier to 
> do it that way.
>
> In general, the convention in graal is that if a platform doesn't 
> support some operation, then this operation should not exist in the 
> final high-level graph. Most of the time, we're doing this with 
> platform specific phases or lowerings.
> In this particular case, I think the best fix is to move the 
> optimization that produces the sub-word compares to x86-specific code, 
> i.e., never produce them on platforms that don't support them instead 
> of having to back out after the fact.
>
> Since we already have two backends that stumble over it, I think it's 
> time to look into fixing this ;)
> I think it shouldn't be too hard. In the meantime, you can just copy 
> the SPARC workaround.
Should be fixed 
(https://github.com/graalvm/graal-core/commit/e276a1dc73876559f2ada69797dcb961076b51f0).

- Roland
>
> - Roland
>>
>> Andrew.
>
>