[PATCH] [x86] fix allowsMisalignedMemoryAccess() implementation

Sanjay Patel spatel at rotateright.com
Tue Jun 23 10:33:37 PDT 2015

Hi qcolombet, jyknight, hfinkel,

The ultimate motivation for this patch is to fix the part of PR21711 ( https://llvm.org/bugs/show_bug.cgi?id=21711#c12 ) that is still not working. To get there, I'd like to use TLI.allowsMisalignedMemoryAccess() in DAGCombiner's MergeConsecutiveStores(). This will require fixing bugs in x86, AArch64 (see post-commit thread for r227242) and possibly other targets.

This patch fixes the x86 implementation of allowsMisalignedMemoryAccess() to correctly return the 'Fast' output parameter for aligned and/or 32-byte loads. To test that, an existing load merging optimization is changed to use the TLI hook. This exposes a shortcoming in the current logic and results in the regression test update. Changing other direct users of the isUnalignedMem32Slow() x86 CPU attribute would be a follow-on patch.

The change to SelectionDAG's FindOptimalMemOpLowering() is needed because once we fix the x86 implementation of allowsMisalignedMemoryAcess(), it exposes a bug in FindOptimalMemOpLowering() alignment checking. Without the change, the 't1' 25-byte memcpy test in test/CodeGen/X86/memcpy-2.ll would generate this:

  movups	_.str+9, %xmm0     <--- unaligned 16-byte load (overlaps with next load)
  movups	%xmm0, 9(%esp)   <--- unaligned 16-byte store (overlaps with next store)
  movaps	_.str, %xmm0         <--- aligned 16-byte load
  movaps	%xmm0, (%esp)    <--- aligned 16-byte store

instead of the expected:
  movsd	_.str+16, %xmm0   <--- aligned 8-byte load
  movsd	%xmm0, 16(%esp) <--- aligned 8-byte store
  movaps	_.str, %xmm0         <--- aligned 16-byte load
  movaps	%xmm0, (%esp)    <--- aligned 16-byte store
  movb	$0, 24(%esp)          <--- final store byte uses immediate value



-------------- next part --------------
A non-text attachment was scrubbed...
Name: D10662.28252.patch
Type: text/x-patch
Size: 4174 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150623/0f1d3398/attachment.bin>

More information about the llvm-commits mailing list