Sub-word comparisons

Roland Schatz roland.schatz at
Fri Nov 4 12:16:16 UTC 2016

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.

- Roland
> Andrew.

More information about the graal-dev mailing list