So I was looking into a horrific schedule for SAD a week or so ago and
came across this gem.
Basically we were treating a vector load as a vector move from a
scheduling standpoint during sched1. Naturally we didn't expose much
ILP during sched1. That in turn caused the register allocator to pack
the pseudos onto the physical vector registers tightly. regrename
didn't do anything useful and the resulting code had too many false
dependencies for sched2 to do anything useful.
As a result we were taking many load->use stalls in x264's SAD routine.
I'm confident the types are fine, but I'm a lot less sure about the
other attributes (mode, avl_type_index, mode_idx). If someone could
take a look at that, it'd be greatly appreciated.
There's other cases that may need similar treatment. But I didn't want
to muck with them until I understood those other attributes and how they
need adjustments.
In particular mov<VLS_AVL_REG:mode><P:mode>_lra appears to have the same
problem.
Jeff
* config/riscv/vector.md (mov<mode> pattern/splitter): Fix type and
other attributes.
diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
index a1d50bc9cea..597a028021b 100644
--- a/gcc/config/riscv/vector.md
+++ b/gcc/config/riscv/vector.md
@@ -1400,7 +1400,10 @@ (define_insn_and_split "*mov<mode>"
gcc_assert (ok_p);
DONE;
}
- [(set_attr "type" "vmov")]
+ [(set_attr "type" "vlde,vste,vmov")
+ (set_attr "mode" "<MODE>")
+ (set (attr "avl_type_idx") (const_int INVALID_ATTRIBUTE))
+ (set (attr "mode_idx") (const_int INVALID_ATTRIBUTE))]
)
(define_expand "mov<mode>"
