> 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. -- Regards Robin
