On 11/12/24 7:32 AM, Robin Dapp wrote:
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
Those additional attributes are purely(?)/mostly for the vsetvl pass which
uses them to read and modify insn properties. The necessary "vsetvl mode"
for example is sometimes the insn's src mode and sometimes the dest's.
As we always split before vsetvl the attributes shouldn't matter on those
unsplit/ephemeral insns.
That's basically what I suspected. I'll post an updated patch that
includes a fix for that other pattern to get it run through the
pre-commit tester.
Jeff
