Details
Diff Detail
Event Timeline
I'm stopping reviewing here. Please create a separate patch for the changes in SymbolicallyEvaluateGEP.
include/llvm/Analysis/ConstantFolding.h | ||
---|---|---|
50–55 | Instead of introducing this function with the implicit requirement of having to provide InstOrCE if Opcode == Instruction::GetElementPtr, this should be made explicit by introducing a function specifically for GEPs (similar to ConstantFoldCompareInstOperands()). | |
lib/Analysis/ConstantFolding.cpp | ||
729–730 | The lack of consistency of parameter names is slightly confusing here. Am I right that ResultTy is the pointer type of the GEP, and SrcTy and ResultElementTy are pointee types? | |
734 | Ptr is always a constant of pointer type, right? I'll remove this check in a separate commit. |
include/llvm/Analysis/ConstantFolding.h | ||
---|---|---|
50–55 | That's not really possible without introducing a special case at each call site. |
Moved the invocation of SymbolicallyEvaluateGEP and its StructType handling to simplify the patch.
lib/Analysis/ConstantFolding.cpp | ||
---|---|---|
739 | How/why did this get rolled in here? |
LGTM
lib/Analysis/ConstantFolding.cpp | ||
---|---|---|
733–736 | Actually Ptr can also be a vector of pointers here. I have reverted the commit in which I moved this check to an assertion. When merging / rebasing, make sure to include the isPointerTy() check, but *not* the assertion. |
lib/Analysis/ConstantFolding.cpp | ||
---|---|---|
739 | I had two calls to SymbolicallyEvaluateGEP at some point and it was easier to have it here than two CastGEPIndices at each site. IMO CastGEPIndices shouldn't bother creating a GEP ConstantExpression but rather change what Ops in this function points to (if any indices were cast). |
lib/Analysis/ConstantFolding.cpp | ||
---|---|---|
739 | Realize that, to speed throughput, I'm looking at these changes /really/ superficially/mechanically. Anything that's more than a very local change for accessing type information slows me down a fair bit & I may not understand it fully. (case in point here - I haven't looked at what this function is trying to do or how it might best do that - just at whether the behavior seems to be preserved by moving around the type information and how it's accessed) :) So the more you can help me understand anything more complicated than that (or avoid such complications/separate them into pre or post patches), the better. | |
860 | Was this dead code previously? |
Instead of introducing this function with the implicit requirement of having to provide InstOrCE if Opcode == Instruction::GetElementPtr, this should be made explicit by introducing a function specifically for GEPs (similar to ConstantFoldCompareInstOperands()).