This was found when working on D64193. On PowerPC if we turn off VSX feature, we'll get an ICE complaining null table entry in ScalarizeVecRes_StrictFPOp. Here we use the same workaround in ScalarizeVecRes_UnaryOp and ScalarizeVecRes_SETCC.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
170 ms | lldb-unit.Host/_/HostTests::Unknown Unit Message ("") |
Event Timeline
llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp | ||
---|---|---|
229 | Can this if-else be rolled into the generic loop below? Or is there a reason that's not ok? |
llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp | ||
---|---|---|
229 | The generic loop below skips the first operand so we should just be able to put this getTypeAction and EXTRACT_VECTOR_ELT handling into that loop. |
llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp | ||
---|---|---|
229 | Thanks for reminder! I misunderstood the comment. |
llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp | ||
---|---|---|
229 | Should we copy the workaround comment from ScalarizeVecRes_UnaryOp(...) to this change? The workaround is pretty confusing to me, but I'm not an expert here. |
I don't think this is needed for PowerPC after 1a493b0fa556a07c728862c3c3f70bfd8683bef0.
We really should be scalarizing single element vectors and after that change, we will.
@nemanjai : I don't think this is needed for PowerPC after 1a493b0fa556a07c728862c3c3f70bfd8683bef0.
It works. Thanks!
Can this if-else be rolled into the generic loop below? Or is there a reason that's not ok?