- 
                Notifications
    
You must be signed in to change notification settings  - Fork 15.1k
 
[AArch64][CostModel] Consider i32 --> i64 partial reduce cost as Invalid for FixedLength vectors #165226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
[AArch64][CostModel] Consider i32 --> i64 partial reduce cost as Invalid for FixedLength vectors #165226
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | 
|---|---|---|
| 
          
            
          
           | 
    @@ -5757,8 +5757,15 @@ InstructionCost AArch64TTIImpl::getPartialReductionCost( | |
| return Cost; | ||
| } | ||
| 
     | 
||
| if (!ST->useSVEForFixedLengthVectors() && | ||
| (AccumLT.second.isFixedLengthVector() && ST->isNeonAvailable() && | ||
| ST->hasDotProd()) && | ||
| 
         
      Comment on lines
    
      +5761
     to 
      +5762
    
   
  There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If I understand the optimization guide correctly, this should not just return Invalid for fixed-length vectors? My suggestion would be to only handle this case if the i32->i64 dot product instructions are available (added by SVE2p1 or SME2) and to return  There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 
 Will add test cases for SVE2p1 or SME2 in some other PR 
 I am not sure if returning  
  | 
||
| (AccumLT.second.getScalarType() == MVT::i64 && | ||
| InputLT.second.getScalarType() == MVT::i32)) | ||
| return Invalid; | ||
| 
         There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't understand why you're returning 'Invalid' here when we can actually generate code for the intrinsic, i.e. gets lowered to I think this just needs to have a cost that reflects what the generated code looks like. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As explained in the writeup, this gets lowered to SMLAL[BT] when SVE2 is available as described by state T3 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If I prevent this Neon to SVE lowering, it creates dependencies in the code Now resolving this at codegen level is difficult because of : There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. An Invalid cost is currently used by the AArch64 cost model to imply "this cannot be lowered", whereas what you're saying is that it can be lowered, but the cost could be high. I would prefer this to simply use a conservative high cost rather than Invalid. Is there anything preventing you from using a high cost? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Lets suppose that we return arbitrary high cost as PR #158641 was already doing. I dont know how the Initial vplan is constructed, but looking at the debug logs, it seems that once the partial reduce cost is valid(even though its high), it doesnt consider the possibility of vplan without the instrinsics and hence, we get code with VF=2 as in state T2  | 
||
| 
     | 
||
| // Add additional cost for the extends that would need to be inserted. | ||
| return Cost + 2; | ||
| return Cost + 4; | ||
| 
         There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When I change this back to   | 
||
| } | ||
| 
     | 
||
| InstructionCost | ||
| 
          
            
          
           | 
    ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's worth adding a comment here to describe why we do this, along with a FIXME to suggest this is a workaround.
The way things currently work is as follows:
This means that if you don't want the LV to choose a VPlan with partial reductions for the given types, because we prefer the use of regular reductions for that loop, then the cost-model should return
Invalid.If we want to use partial reductions for these types, and prefer it over other partial reductions, then we should return a valid (but lower) cost.
The comment I would suggest would be something like:
The more structural way to address the FIXME would be to stop making this decision early on and instead decide if partial reductions are favoured over regular reductions, so that we compare the "best reduction plan" for the given VF to the "best reduction plan" for another VF. Whereas now it compares a partial reduction plan for the given VF to another (partial/non-partial) reduction plan for another VF. This is something we're planning to fix, but it requires some bigger changes to how the LV handles partial reductions.