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