This is an archive of the discontinued LLVM Phabricator instance.

[DAG] Allow folding AND of anyext masked_load with >1 user to zext version
ClosedPublic

Authored by benmxwl-arm on Nov 11 2022, 7:33 AM.

Details

Summary

This now allows folding an AND of a anyext masked_load to a zext_masked_load even if the masked load has multiple users.
Doing is eliminates some redundant ANDs/MOVs for certain AArch64 SVE code.

I'm not sure if there's any cases where doing this could negatively the other users of the masked_load.
Looking at other optimizations of masked loads, most don't apply if the load is used more than once, so it doesn't look like this would interfere.

Diff Detail

Event Timeline

benmxwl-arm created this revision.Nov 11 2022, 7:33 AM
benmxwl-arm requested review of this revision.Nov 11 2022, 7:33 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 11 2022, 7:33 AM

Remove accidentally committed file

Matt added a subscriber: Matt.Nov 11 2022, 7:30 PM

Replace the loads in the same way tryToFoldExtOfLoad() handles it. This avoids some errors in the DAG.

benmxwl-arm retitled this revision from [DAG] Fold zext/sext into masked loads with multiple truncate uses to [DAG] Allow folding zext/sext into masked loads with multiple uses.Nov 14 2022, 5:31 AM
benmxwl-arm edited the summary of this revision. (Show Details)
benmxwl-arm edited the summary of this revision. (Show Details)

Corrected isTruncateFree() check for existing users.

llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
12121

V is N0, so do you need to close over N0?

12131

Is it necessary to bail out for these cases, or would they still be handled by the isTruncFree logic? If you want to have the FIXME, it may be worth referencing ExtendUsesToFormExtLoad.

benmxwl-arm added inline comments.Nov 15 2022, 3:01 AM
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
12121

I also close over VT and TLI, so I guess I could just use the closed N0 too.

12131

I'm not sure it's covered by the isTruncFree logic. The SETCC case is handled for the other loads by keeping a list of the SETCC nodes, then extending their other operands to match the new extended load.

(This is only done for sign-extension, otherwise the transform load transform is not applied).

When there's live in/out nodes the number of SETCCs is used to decide if the transform is worth it.

benmxwl-arm updated this revision to Diff 475506.EditedNov 15 2022, 9:23 AM

Updated to a simpler solution for the same problem.

This now allows folding an AND of a anyext masked_load to a zext_masked_load even if the masked load has multiple users.
Doing is eliminates some redundant ANDs/MOVs for certain AArch64 SVE code.

I'm not sure if there's any cases where doing this could negatively the other users of the masked_load.
Looking at other optimizations of masked loads, most don't apply if the load is used more than once, so it doesn't look like this would interfere.

benmxwl-arm retitled this revision from [DAG] Allow folding zext/sext into masked loads with multiple uses to [DAG] Allow folding AND of anyext masked_load with >1 user to zext version.Nov 15 2022, 9:25 AM
benmxwl-arm edited the summary of this revision. (Show Details)
benmxwl-arm marked 2 inline comments as done.

Marking Peter's comments as done as they no longer apply to this version.

benmxwl-arm edited the summary of this revision. (Show Details)Nov 15 2022, 9:31 AM

this looks ok to me, but it would be good to get confirmation it's ok to remove the hasOneUse check on the masked load, @samtebbs @RKSimon any reason we might not want to do this?

From my reading an anyext can't guarantee what is put in those extended bits so changing the anyext to a zext seems semantically acceptable to me. If it isn't correct then we'll get some bug reports and it can be fixed!

c-rhodes accepted this revision.Nov 17 2022, 6:00 AM

From my reading an anyext can't guarantee what is put in those extended bits so changing the anyext to a zext seems semantically acceptable to me. If it isn't correct then we'll get some bug reports and it can be fixed!

Great, sounds good. thanks for taking a look. LGTM.

This revision is now accepted and ready to land.Nov 17 2022, 6:00 AM
This revision was landed with ongoing or failed builds.Nov 18 2022, 2:38 AM
This revision was automatically updated to reflect the committed changes.