Per discussion in D92083, the legalizer needs to handle such cases.
Details
- Reviewers
craig.topper pengfei RKSimon spatel nemanjai jsji shchenz - Group Reviewers
Restricted Project - Commits
- rG15826eb43746: [Legalizer] Avoid expansion to BR_CC if illegal
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/test/CodeGen/PowerPC/f128-branch-cond.ll | ||
---|---|---|
5 | Missing the check contents? |
llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp | ||
---|---|---|
3714 | Just curious, will it be possible that the new BR_CC is still not legalized? And thus leading to an infinite loop here? |
If I'm reading the debug logs right, we started from a BRCOND with a SETCC input, the was expanded to an unsupported BR_CC. So now we need to expand the BR_CC. Should we have just checked for BR_CC legality before expanding the BRCOND using BR_CC?
llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp | ||
---|---|---|
3562 | Here when BR_CC is not legal, Results should be empty. |
llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp | ||
---|---|---|
3562 | If it's not legal, won't we go to the else which will always push something to Results? |
Thanks. LGTM. Please hold on some days in case other reviewers like @craig.topper have further comments.
llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp | ||
---|---|---|
3558 | I think we need to go to the else case. We shouldn't leave this function without pushing something to the Results vector. Anything that doesn't push to the Results vector, will try libcall expansion. But there is no libcall for BRCOND so we fail that too. The debug log contains these messages Trying to expand node Cannot expand node Trying to convert node to libcall Could not convert node to libcall I think after that the BRCOND will stick around even though it isn't "legal". After that the SETCC gets letalized to a SELECT_CC. Once we leave op legalization, the last DAG combine runs. That will call back into this function to try to legalize the still illegal BRCOND. The input is no longer a SETCC so it falls to the else case here which finally legalizes it. We should have just gone to the else the first time. It's creating a BR_CC on i32 not on fp128 so it should be fine. |
I think we need to go to the else case. We shouldn't leave this function without pushing something to the Results vector. Anything that doesn't push to the Results vector, will try libcall expansion. But there is no libcall for BRCOND so we fail that too. The debug log contains these messages
I think after that the BRCOND will stick around even though it isn't "legal". After that the SETCC gets letalized to a SELECT_CC. Once we leave op legalization, the last DAG combine runs. That will call back into this function to try to legalize the still illegal BRCOND. The input is no longer a SETCC so it falls to the else case here which finally legalizes it.
We should have just gone to the else the first time. It's creating a BR_CC on i32 not on fp128 so it should be fine.