This is an archive of the discontinued LLVM Phabricator instance.

[AArch64] Sink sext when foldable in user GEPs
AbandonedPublic

Authored by junbuml on Nov 10 2016, 2:03 PM.

Details

Summary

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.

Diff Detail

Event Timeline

junbuml updated this revision to Diff 77552.Nov 10 2016, 2:03 PM
junbuml retitled this revision from to [AArch64] Sink sext when foldable in user GEPs.
junbuml updated this object.
junbuml added a subscriber: llvm-commits.
jmolloy requested changes to this revision.Nov 11 2016, 12:32 AM
jmolloy edited edge metadata.
jmolloy added inline comments.
lib/Target/AArch64/AArch64AddressTypePromotion.cpp
140

"performSink" is so generic - can we call it something more specific like "sinkSExt" ?

376

Same here - "isAllFoldable" - can we make that clear we're referring to SExts?

385

You shouldn't need these clear() operations, because this array will not be used if we return false.

394

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.

This revision now requires changes to proceed.Nov 11 2016, 12:32 AM
junbuml updated this revision to Diff 77623.Nov 11 2016, 9:04 AM
junbuml edited edge metadata.

Addressed James' comments. Thanks James for the review.

junbuml updated this revision to Diff 77628.Nov 11 2016, 9:12 AM
junbuml edited edge metadata.
junbuml marked 3 inline comments as done.
junbuml added inline comments.
lib/Target/AArch64/AArch64AddressTypePromotion.cpp
394

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.

mcrosier added inline comments.Nov 14 2016, 3:18 PM
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
247

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.

247

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.

junbuml abandoned this revision.Dec 16 2016, 11:55 AM

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.