[9] RFR(S): 8075324: Costs of memory operands in aarch64.ad are inconsistent
Tobias Hartmann
tobias.hartmann at oracle.com
Tue Mar 17 12:42:41 UTC 2015
Hi,
please review the following patch.
https://bugs.openjdk.java.net/browse/JDK-8075324
http://cr.openjdk.java.net/~thartmann/8075324/webrev.00/
Problem:
The costs of memory operands in aarch64.ad are inconsistent. The following operands have cost 0:
- indirect
- indIndexScaledI2L
- indIndexScaled
- indIndex
- indOffL
- indirectN
- indIndexScaledOffsetIN
- indIndexScaledI2LN
- indIndexScaledN
- indIndexN
- indOffIN
- indOffLN
Whereas the following operands have cost 'INSN_COST':
- indIndexScaledOffsetI
- indIndexScaledOffsetL
- indIndexScaledOffsetI2L
- indOffI
- indIndexScaledOffsetLN
- indIndexScaledOffsetI2LN
In my opinion there is no reason for 'indOffI' being more expensive than 'indOffL'. Further, the cost 'INSN_COST' is too high and leads to actual instructions like 'addP_reg_reg_ext' being preferred over using memory operands (see problem described in RFR for 8075136 [1]).
Solution:
Use cost 0 for simple (immediate-only) operands:
- indirect
- indIndex
- indOffL
- indirectN
- indIndexN
- indOffIN
- indOffLN
Use cost 10 for more complex operands:
- indIndexScaledOffsetI
- indIndexScaledOffsetL
- indIndexScaledOffsetI2L
- indIndexScaledI2L
- indIndexOffsetI2L
- indIndexScaled
- indIndexScaledOffsetIN
- indIndexScaledOffsetLN
- indIndexScaledOffsetI2LN
- indIndexScaledI2LN
- indIndexOffsetI2LN
- indIndexScaledN
We do the same on x86_64 (see 'indirect' vs. 'indIndexScale').
Thanks,
Tobias
[1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-March/017414.html
More information about the hotspot-compiler-dev
mailing list