All getReductionCost() functions are renamed to getArithmeticReductionCost() + added basic infrastructure to handle non-binary reduction operations.
Details
Diff Detail
Event Timeline
lib/Analysis/CostModel.cpp | ||
---|---|---|
196 | Can this ever be a Value that's not an Instruction? | |
lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
4097 | This basically complements the change in line 4803 - 4823, right, but taken together, those two changes are NFC, regardless of everything else here, right? Or am I confused and this depends on something else? | |
4197 | This part of the change is completely orthogonal to the name change and using matchers, right? Anyway, I think I see where this is going. This is possibly similar to what Ayal, Gil & company are doing for LV, in terms of recipes? | |
4198 | What does being valid mean in this context? Just that this is a "non-null handle" | |
4245 | only adds at this point. :-) | |
4249 | So, by "of the same kind" you mean "both a reduction op or both a reduced value", which is something you determine by either both LHS/RHS being null, or both being non-null? | |
4271 | I've cleaned this up in the existing code, there's no need to special-case FAdd, you can just CreateBinOp for it. |
lib/Analysis/CostModel.cpp | ||
---|---|---|
211 | Can PatternMatch be put to more use, by asking it to match a BinOp whose L and R sides are both shuffles, when Level > 0? Passing L and R by reference here saves little compared to the original direct calls to getOperand(0) and getOperand(1), and seems mostly redundant elsewhere. | |
405 | Check if RdxOp, or use cast instead of dyn_cast? | |
lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
4094 | V is-surely-a<BinaryOperator>, being a non-nullptr to BinaryOperator, right? |
lib/Analysis/CostModel.cpp | ||
---|---|---|
196 | Of course no, only instructions can be used here. I'll convert these params to Instruction *. | |
211 | This is just an initial patch. In future it will be extended with support of min/max patterns, that's why this kind of recognition of LHS/RHS operands is placed in function. Another thing, that it will be better just to return the record of opcode + LHS/RHS parts, rather than pass L/R by reference. | |
405 | Yes, missed this, thanks. Will fix. | |
lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
4094 | Yes, forgot to change type of parameter, will do it | |
4097 | Yes, you're right, I'll remove these changes from this patch and prepare another one for CmpInsts. | |
4197 | No, actually it is basic infrastructure for supporting horizontal reduction vectorization of not-BinOp instructions. It does not change the functionality, but allows later easily to support vectorization of other complex instructions, like min/max. | |
4198 | Will try to remove it | |
4245 | Yes, will fix this. | |
4249 | Yes, it is exactly what I meant. | |
4271 | Ok, will fix it. |
lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
4213 | Should IsReducedValue be set to false here? | |
4249 | The IsReducedValue explicit flag indicates if its a reduction op or reduced value, right? To implement the behavior documented above: "Checks if two operation data are both a reduction op or both a reduced value", it's enough to have the "IsReducedValue == OD.IsReducedValue" part. | |
4267 | re[d]uction |
lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
4094 | I must be missing something here; tryToVectorize() is still being fed by BinaryOperator*, right? Wondering why the parameter type change. Better include this change in follow-up patch which tries to vectorize non BinaryOperators, if that's the intention. | |
4196 | "+ validity" should be removed? | |
4219 | Still a couple of "if (x.Opcode == 0)" cases, may as well make use of this bool(). | |
4245 | isVectorizable() is used only in conjuction with isAssociative(I), and as an assert when getOpcode() is called by getReductionCost(). Isn't it better to have isVectorizable(I) also call isAssociative? | |
4249 | It sounds like you can assert ((IsReducedValue != OD.IsReducedValue) || ((!LHS == !OD.LHS) && (!RHS == !OD.RHS) && Opcode == OD.Opcode) && "message"); no need to actually check them all to return true, right? | |
4267 | typo | |
4269 | Every other method fits with the passive, storage-type "OperationData" name of this struct, but this last method may look a bit odd doing "OperationData.createOp()". All that it's contributing is its Opcode which it can provide, and some asserts. Is there a better way of keeping OperationData's nature, or a better name for it? | |
4744 | Not sure why you wanted this change; but how about simply "if (isa<BinaryOperator>(Inst))"? |
lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
4094 | Restored back. | |
4196 | Removed | |
4219 | Tried to replace all | |
4245 | Added isVectorized(Instruction *I) | |
4249 | Modified it a bit, still need to compare the opcode | |
4267 | Yes, thanks, fixed | |
4269 | Modified this method, now it accepts only Builder and optional name | |
4744 | Restored it |
lib/Analysis/CostModel.cpp | ||
---|---|---|
189 | Contains |
Some minor style comments
lib/Analysis/CostModel.cpp | ||
---|---|---|
202 | No need to initialize these. Value *L, *R; | |
204 | Use the ReductionData constructor for clarity? | |
lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
4228 | ? | |
4233 | Add assert message | |
4238 | Add assert message | |
4243 | Add assert message | |
4301 | Use OperationData constructor for clarity | |
4304 | Add assert message |
A couple of NFC changes that will reduce this patch.
include/llvm/CodeGen/BasicTTIImpl.h | ||
---|---|---|
993 | You should probably move this comment (unchanged) as a NFC commit right away to reduce the patch. I can't tell if you've changed anything. | |
include/llvm/Transforms/Vectorize/SLPVectorizer.h | ||
87 ↗ | (On Diff #101750) | Do this as an NFC commit now - its a tidyup that isn't relevant to the patch. |
There's still a lot going on in this patch but it looks alright to me (I noticed one minor).
Does anyone have any further comments?
lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
4213 | If OperationData is a struct then this public can go? |
Could we split it on 2 sub-parts:
1 - rename (maybe NFC?)
2 - new infrastructure
In this case it will be easier and smaller.
LGTM - if possible please commit the getArithmeticReductionCost rename as a separate pre-commit.
You should probably move this comment (unchanged) as a NFC commit right away to reduce the patch. I can't tell if you've changed anything.