[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