[LLVMdev] Bug in visitSIGN_EXTEND in DAGCombiner.cpp?
Richard.Relph at amd.com
Mon Mar 11 12:58:01 PDT 2013
On Mar 11, 2013, at 11:27 AM, Nadav Rotem <nrotem at apple.com<mailto:nrotem at apple.com>>
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.
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 ?
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… ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev