Sub-word comparisons
Roland Schatz
roland.schatz at oracle.com
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