[llvm-dev] InstCombine question on combineLoadToOperationType

Pete Couperus via llvm-dev
Thu, 17 Nov 2016 16:28:46 -0000

On 11/15/2016 4:22 PM, Pete Couperus via llvm-dev wrote:
Hello,

Context: We have a backend where v32i1 is a Legal type, but the storage for
v32i1 is not 32-bits/uses a different instruction sequence.
We ran into an issue because combineLoadToOperationType changed v32i1 loads into
i32 loads, so a sequence like:
define void @bits(<32 x i1>* %A, <32 x i1>* %B) {
  %a = load <32 x i1>, <32 x i1>* %A
  store <32 x i1> %a, <32 x i1>* %B
  ret void
}

Is transformed to:
define void @bits(<32 x i1>* %A, <32 x i1>* %B) {
  %1 = bitcast <32 x i1>* %A to i32*
  %a1 = load i32, i32* %1, align 4
  %2 = bitcast <32 x i1>* %B to i32*
  store i32 %a1, i32* %2, align 4
  ret void
}

This looks to be intentional.
Is there a way to specify in the data-layout that v32i1 storage is not 32-bits?

No, not at the moment.  You could propose something, but you'd probably have
a hard time convincing anyone it's necessary; nobody has cared about this
for a very long time.


Absent that, is there any other reliable way to retain the original vector
loads/store without just disabling this part of InstCombine?

No, and you'll run into other problems (e.g. alias analysis) if the data
layout lies about the size of a load or store.


Or is it the backend’s responsibility to try and work with this?

Where are these loads coming from?  x86 without AVX512 doesn't have any
convenient way generate code for a <32 x i1> store, but it doesn't
matter because frontends don't generate <N x i1> loads and stores.

If you have a frontend which is generating loads and stores like this, you could
probably change it to use some other sequence (like a platform-specific
intrinsic, or some sequence involving sext/trunc).


We do have a frontend that can generate <32 x i1> loads/stores, though it
is rare that these are inst-combined to i32 loads/stores like here (these were
only illustrative examples).
I’m trying to decide what the best way to remedy this is, and this info and
suggestions help.
Thanks!

Pete

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161117/1e9aaff1/attachment.html>