[PATCH] D91294: [X86] When storing v1i1/v2i1/v4i1 to memory, make sure we store zeros in the rest of the byte

Craig Topper via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 11 13:09:19 PST 2020


craig.topper created this revision.
craig.topper added reviewers: pengfei, RKSimon, spatel, Treebeard.
Herald added a subscriber: hiraditya.
Herald added a project: LLVM.
craig.topper requested review of this revision.

We can't store garbage in the unused bits. It possible that something like zextload from i1/i2/i4 is created to read the memory. Those zextloads would be legalized assuming the extra bits are 0.

I'm not sure that the code in lowerStore is executed for the v1i1/v2i1/v4i1 case. It looks like the DAG combine in combineStore may have converted them to v8i1 first. And I think we're missing some cases to avoid going to the stack in the first place. But I don't have time to investigate those things at the moment so I wanted to focus on the correctness issue.

Should fix PR48147.


https://reviews.llvm.org/D91294

Files:
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/lib/Target/X86/X86InstrAVX512.td
  llvm/test/CodeGen/X86/avx512-extract-subvector-load-store.ll
  llvm/test/CodeGen/X86/avx512-load-trunc-store-i1.ll
  llvm/test/CodeGen/X86/avx512-mask-op.ll
  llvm/test/CodeGen/X86/avx512-select.ll
  llvm/test/CodeGen/X86/stack-folding-avx512vp2intersect.ll
  llvm/test/CodeGen/X86/vec_saddo.ll
  llvm/test/CodeGen/X86/vec_smulo.ll
  llvm/test/CodeGen/X86/vec_ssubo.ll
  llvm/test/CodeGen/X86/vec_uaddo.ll
  llvm/test/CodeGen/X86/vec_umulo.ll
  llvm/test/CodeGen/X86/vec_usubo.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D91294.304626.patch
Type: text/x-patch
Size: 47597 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20201111/04f02099/attachment-0001.bin>


More information about the llvm-commits mailing list