Sink sign extensions to user blocks if foldable as a part of address calculation by the local ISel when placed in the same block. With this change, 3% performance gain was observed in spec2006/astar. The test case was reduced from spec2006/astar wayobj::makebound2() function.
Details
Diff Detail
Event Timeline
lib/Target/AArch64/AArch64AddressTypePromotion.cpp | ||
---|---|---|
140 | "performSink" is so generic - can we call it something more specific like "sinkSExt" ? | |
377 | Same here - "isAllFoldable" - can we make that clear we're referring to SExts? | |
386 | You shouldn't need these clear() operations, because this array will not be used if we return false. | |
395 | Shouldn't this function only succeed if the SExt was the *last* operand in the GEP? We can't represent a GEP such as: %0 = sext i16 %idx to i32 %1 = gep inbounds i32* %base, i32 %0, i32 6 So I think this function is not conservative enough. |
lib/Target/AArch64/AArch64AddressTypePromotion.cpp | ||
---|---|---|
395 | If we are accessing an element from a struct pointer, such GEP could be used where a constant is placed after the sext to index the element in struct. The test case shows such case. For example, if you see func_16B(), %addr2 is to access the 2nd element in %struct.16B : %addr2 = getelementptr inbounds %struct.16B, %struct.16B* %P, i64 %s_ext, i32 1 Since all other indexes are constants, it will end up with a simple add in the form of %base + TypeSize * sext + constant, where the sext is used to index a struct object from the struct array. |
lib/Target/AArch64/AArch64AddressTypePromotion.cpp | ||
---|---|---|
131 | It would probably be a good idea to rename this method and update the comment accordingly now that this logic both hoists common sexts and sinks foldable sexts. Unfortunately, I can't come up with a good name off the top of my head. | |
test/CodeGen/AArch64/aarch64-address-type-promotion-sink.ll | ||
246 | I don't think you're using the CHECK-LABEL directive the way it is intended here (i.e., the %if.then label isn't unique to this file). I suggest using a regular CHECK. | |
246 | You can ignore this comment. I tried to remove it, but Phab wasn't taking the change. I think your usage is okay.. |
Hi,
When I first implemented this pass the intent was to get insights on how to do that in a generic way. Then, we added some logic to do that transformation as part of CGP. The goal was to kill that pass once and for all.
The bottom line is instead of improving this pass, could teach the generic framework in CGP?
Cheers,
Quentin
When I first implemented this pass the intent was to get insights on how to do that in a generic way. Then, we added some logic to do that transformation as part of CGP. The goal was to kill that pass once and for all. The bottom line is instead of improving this pass, could teach the generic framework in CGP?
That makes sense. Let me try to make this more general in CGP. Thanks Quentin.
Before we perform this transformation in CGP, I think we need to move this pass into CGP first. So, my plan is to extend moveExtToFormExtLoad() to cover the transformation done in this pass. Instead of just looking for a mergeable load in extLdPromotion() , I will look up heads of chains like analyzeSExtension() in aarch64-type-promotion using existing code (TypePromotionTransaction and TypePromotionHelper) and then promote SExts which derived from the same header. The new extension in CGP will be enabled in AArch64 at first. Please let me know if there is any suggestion or concern regarding the migration of this pass into CGP.
My plan is to move aarch64-type-promotion pass into CGP first, and then perform the transformation proposed in this change in CGP. As a part of that, I first restructured the current implementation in CGP in D27853.
It would probably be a good idea to rename this method and update the comment accordingly now that this logic both hoists common sexts and sinks foldable sexts. Unfortunately, I can't come up with a good name off the top of my head.