Workaround MSVC 32-bit miscompile of getCondCodeAction.
authorMatt Arsenault <Matthew.Arsenault@amd.com>
Tue, 29 Oct 2013 20:59:29 +0000 (20:59 +0000)
committerMatt Arsenault <Matthew.Arsenault@amd.com>
Tue, 29 Oct 2013 20:59:29 +0000 (20:59 +0000)
commit2b0002b579dba5604a2673bbee2cd9969e183a71
tree6a0a29807f6406e8efcda11a24e0eeada14d292d
parent5203b7773e29b36e38aac0ce9358fa7843065681
Workaround MSVC 32-bit miscompile of getCondCodeAction.

Use 32-bit types for the array instead of 64. This should
generally be better anyway.

In optimized + assert builds, I saw a failure when a
cond code / type combination that is never set was loading
a non-zero value and hitting the != Promote assert.

It turns out when loading the 64-bit value to do the shift,
the assembly loads the 2 32-bit halves from non-consecutive
addresses. The address the second half of the loaded uint64_t
doesn't include the offset of the array in the struct. Instead
of being offset + 4, it's just + 4.

I'm not entirely sure why this wasn't observed before.
setCondCodeAction isn't heavily used by the in-tree targets,
and not with the higher valued vector SimpleValueTypes. Only
PPC is using one of the > 32 valued types, and that is probably
never used by anyone on a 32-bit MSVC compiled host.

I ran into this when upgrading LLVM versions, so I guess the
value loaded from the nonsense address happened to work out
before.

No test since I'm not really sure if / how it can be reproduced
with the current in tree targets, and it's not supposed to change
anything.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193650 91177308-0d34-0410-b5e6-96231b3b80d8
include/llvm/Target/TargetLowering.h