diff options
author | Robin Dapp <rdapp@ventanamicro.com> | 2024-11-25 12:40:53 +0100 |
---|---|---|
committer | Robin Dapp <rdapp@ventanamicro.com> | 2024-11-26 09:51:54 +0100 |
commit | 9c82afd42e7b5c3bdb849c66879138e59d8eb866 (patch) | |
tree | 66a5f6bbb615eed8e26b30895cab3778c5b102b3 /gcc/fortran/trans-expr.cc | |
parent | 5bb36d832c955e575bd458a02f3c6c5b28564aed (diff) | |
download | gcc-9c82afd42e7b5c3bdb849c66879138e59d8eb866.zip gcc-9c82afd42e7b5c3bdb849c66879138e59d8eb866.tar.gz gcc-9c82afd42e7b5c3bdb849c66879138e59d8eb866.tar.bz2 |
RISC-V: avlprop: Do not propagate VL from slidedown.
In the following situation (found in the
rvv/autovec/vls-vlmax/shuffle-slide.c test which is not yet pushed)
vsetivli zero,4,e8,mf4,ta,ma
vle8.v v2,0(a1) # (1)
vle8.v v1,0(a2) # (2)
vsetivli zero,2,e8,mf4,tu,ma
vslidedown.vi v1,v2,2
vsetivli zero,4,e8,mf4,ta,ma
vse8.v v1,0(a2)
we wrongly "propagate" VL=2 from vslidedown into the load.
Although we check whether the "target" instruction has a merge operand
the check only handles cases where the merge operand itself is
loaded, like (2) in the snippet above. For (1) we load the non-merged
operand, assume propagation is valid and continue despite (2).
This patch just re-uses avl_can_be_propagated_p in order to disable
slides altogether in such situations.
gcc/ChangeLog:
* config/riscv/riscv-avlprop.cc (pass_avlprop::get_vlmax_ta_preferred_avl):
Check whether the use insn is valid for propagation.
Diffstat (limited to 'gcc/fortran/trans-expr.cc')
0 files changed, 0 insertions, 0 deletions