> On 12 Apr 2018, at 13:53, Jakub Jelinek <ja...@redhat.com> wrote: > > On Thu, Apr 12, 2018 at 01:46:40PM +0300, Kirill Yukhin wrote: >> >> Hello Jakub! >> >>> On 11 Apr 2018, at 16:27, Jakub Jelinek <ja...@redhat.com> wrote: >>> In lots of patterns we assume that we never see xmm16+ hard registers >>> with 128-bit and 256-bit vector modes when not -mavx512vl, because >>> HARD_REGNO_MODE_OK refuses those. >>> Unfortunately, as this testcase and patch shows, the vec_extract_lo* >>> splitters work as a loophole around this, we happily create instructions >>> like (set (reg:V32QI xmm5) (reg:V32QI xmm16)) and then hard register >>> propagation can propagate the V32QI xmm16 into other insns like vpand. >>> >>> The following patch fixes it by making sure we never create such registers, >>> just emit (set (reg:V64QI xmm5) (reg:V64QI xmm16)) instead, which by copying >>> all the 512 bits also copies the low bits, and as the destination is >>> originally V32QI which is not HARD_REGNO_MODE_OK in xmm16+, this should be >>> fine. >>> >>> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? >> Patch is OK for trunk. > > I've posted an updated version of this patch later on in > https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00563.html > Is that one ok for trunk instead? Yes.
— Thanks, K > > And sorry for not getting it right the first time. > > Jakub
