Details
- Reviewers
arsenm Peter - Group Reviewers
Restricted Project - Commits
- rG8901f7cebc73: [AMDGPU] Fix crash legalizing G_EXTRACT_VECTOR_ELT with negative index
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
IdxVal >= 0 check looks fine to me,
but what looks wrong in this test is that i1 1(true in llvm ir) index is translated to %7:_(s32) = G_CONSTANT i32 -1
IRTranslator::translateExtractElement did not expect i1 indices and since indices are (afaik) positive zext would make more sense then sext in:
APInt NewIdx = CI->getValue().sextOrTrunc(PreferredVecIdxWidth);
->
APInt NewIdx = CI->getValue().zextOrTrunc(PreferredVecIdxWidth);
Language ref does not specify required type for index, although we probably expected i32,
vector in test %I has two elements and i1 is enough to hold index, so globalisel should probably treat i1 true and false as 0 and 1 i32 indices .
Agreed, indexes should be unsigned, and this should be documented in the LangRef like it is for the shl instruction: ‘op2’ is treated as an unsigned value.
Agree. This case seems unique to i1. Any other index with negative constant value would be ignored by translator.
llvm/lib/Target/AMDGPU/AMDGPULegalizerInfo.cpp | ||
---|---|---|
2392 | You might want to add the non-negative test here too. However, I haven't been able to find a test case that crashed here yet. |
I'd somewhat prefer a mir test for this in case some IR optimization decided to start deleting these earlier
The type conversion in the IRTranslator surprises me. I would expect to pass through the IR type and let the legalizer deal with it
llvm/lib/Target/AMDGPU/AMDGPULegalizerInfo.cpp | ||
---|---|---|
2346 | Why not switch this to getZExtValue? | |
llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-extractelement-crash.ll | ||
2 | -global-isel to the front |
Why not switch this to getZExtValue?