The test case added in this commit includes reduced IR from a test
that failed when dumping the IR in textual form (e.g. when outputting
the .ll file). In general it is a known problem that one could end
up with huge constant expressions that aren't friendly to the
textual format at hand, see for example PR38538 for another example.
However, in the test case added here it should be possible to fold
the constant expression but there seem to be some problem with the
SimplifyCastInst having problems to fold the cast expression if the
operand isn't folded already. And some passes (such as SROA) seem to
generate constant expressions that aren't folded already.
Details
Details
- Reviewers
spatel nikic lebedev.ri
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
| llvm/lib/Analysis/InstructionSimplify.cpp | ||
|---|---|---|
| 4552 | Maybe this is an ugly solution. But I could not really figure out what to do. I had some problems with infinite recursion if doing this directly inside ConstantFoldCastOperand. That is why this patch is doing it before the call to ConstantFoldCastOperand. Should ConstantFoldCastOperand expect that operands already are folded (kind of like in this patch), and then the implementation of ConstantFoldCastOperand doesn't need to handle recursive folding? | |
Comment Actions
This looks somewhat suspect to me. Why is it important that InstSimplify specifically handles this? For example, I would expect InstCombine to take care of this, as it does operand constant folding.
Comment Actions
Yes, instcombine would do this simplification. That is how I figured out that ConstantFoldConstant actually would do the trick. One could of course argue about the usefulness. In this case I guess it was about phase ordering and that one couldn't dump the IR without running instcombine first. Kind of making bisecting and fuzzy testing of single passes a bit more complicated.