[LLVMdev] Bug in visitSIGN_EXTEND in DAGCombiner.cpp?

[Relph, Richard]

On Mar 11, 2013, at 11:27 AM, Nadav Rotem <nrotem at apple.com<mailto:nrotem at apple.com>>
 wrote:


Line 4501 in trunk DAGCombiner.cpp… I changed the ISD::SELECT to the VT.isVector() ? ISD::VSELECT : ISD::SELECT...


Thanks. From the commit message I think that we should only run this optimization on scalars.

I


Can you write down the input SDNode ?  What types are inputs ?

          0x107046d10: v2i8 = vselect 0x107046c10, 0x107046b10, 0x107045e10 [ID=-3]

            0x107046c10: v2i32 = setcc 0x107045c10, 0x107045e10, 0x107045f10 [ID=-3]
           0x107046b10: v2i8 = BUILD_VECTOR 0x107046a10, 0x107046a10 [ID=-3]
  0x107046a10: i8 = Constant<-1> [ID=-3]
  0x107045e10: v2i8 = BUILD_VECTOR 0x107045d10, 0x107045d10 [ORD=10] [ID=-3]
  0x107045d10: i8 = Constant<0> [ORD=10] [ID=-3]

It looks like a type-legalization problem. Is v2i8 a legal type on your architecture ?

Sort of…
v2 certainly is. But we have no actual i8 (or i16) registers and I think our current description (via .td files) says we do. We also don't have an i8 or i16 and/or/xor… but again I think we say we do.
I tweaked ExpandVSELECT() to generate a TRUNCATE if the mask has more bits than the operands… That works for me.

But then I also had to tweak SplitRes_SELECT() in LegalizeTypesGeneric.cpp to avoid the assert there that tests that the SELECT has a MVT::i1 condition. I use the Cond.getValueType().getVectorElementType() to generate the split vector type instead of using a hard-coded MVT::i1. (This is necessary for v8 and v16 types, since our target only natively supports v4 types.)

With the whole suite of 3 minor (? ;-) changes, I'm able to get through my test suite (a large subset of the OpenCL conformance suite) with my target (AMDIL), a target that worked with LLVM 3.1...

 In any case, we can't XOR the mask with the operands because they are not the same width. You can custom-lower VSELECTS to work around this problem.

Thanks. I was hoping to avoid that… ;-)


Thanks,
Nadav

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