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? And sorry for not getting it right the first time. Jakub
