RFR(S): 8154943: AArch64: redundant address computation instructions with vectorization
Dean Long
dean.long at oracle.com
Thu Apr 28 20:24:25 UTC 2016
Are there any platforms where this won't help?
How about adding a Matcher function instead of a cpu-specific ifdef.
dl
On 4/28/2016 9:35 AM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8154943/webrev.00/
>
> Example generated code:
>
> ;; B106: # B106 B107 <- B105 B106 Loop: B106-B106 inner main of N612 Freq: 293550
>
> 0x000003ffa9275650: sbfiz x0, x4, #3, #32
> 0x000003ffa9275654: add x3, x5, x0
> 0x000003ffa9275658: sbfiz x7, x4, #3, #32
> 0x000003ffa927565c: ldr q19, [x3,#16]
> 0x000003ffa9275660: add x19, x5, x7
> 0x000003ffa9275664: ldr q20, [x19,#32] ;*daload {reexecute=0 rethrow=0 return_oop=0}
> ; - jnt.scimark2.LU::factor at 237 (line 235)
>
> both sbfiz and add are strictly indentical and so fully redundant. The
> redundant instructions are caused by 2 ConvI2L nodes that are identical
> except for their type:
>
> 1984 ConvI2L _ 1683 [ 1987 ] debug_idx = 33701984 type = long: dump_spec = #long:minint..maxint-1:www
> 1678 ConvI2L _ 1683 [ 1672 ] bci = 49 debug_orig = dump_spec = #long:0..maxint-1:www debug_idx = 30401678 line = 183 type = long:
>
> The type doesn't help code generation on arm so it could be widened and
> duplicated instructions could then be removed. I think the same could be
> done on sparc.
>
> Roland.
More information about the hotspot-compiler-dev
mailing list