This is an archive of the discontinued LLVM Phabricator instance.

[ScalarizeMaskedMemIntrin] Use the element type to calculate alignment for gather/scatter when alignment operand is 0.
ClosedPublic

Authored by craig.topper on Jun 30 2021, 11:41 AM.

Details

Summary

Previously we used the vector type, but we're loading/storing
invididual elements so I think only element alignment should matter.

Noticed while looking at the code for something else so I don't
have a test case.

Diff Detail

Event Timeline

craig.topper created this revision.Jun 30 2021, 11:41 AM
craig.topper requested review of this revision.Jun 30 2021, 11:41 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 30 2021, 11:41 AM

I think this is correct.
I guess for that you need to pass 0 into alignment argument of these intrinsics.

I think this is correct.
I guess for that you need to pass 0 into alignment argument of these intrinsics.

Yeah. And to have an observable change you need a target with a cost model that returns a different answer if you give it element alignment versus vector alignment. But since gather works on elements, I would expect that any cost model that cares about alignment is checking whether it is element aligned or not.

Instead of messing with this, can we just change the verifier to require that the alignment argument to masked_gather is nonzero? (And teach autoupgrade to fix old code.) This is just a lesser version of the same mess we used to have with other load/store operations.

If you're going to fix it this way, though, please also fix SelectionDAGBuilder.

Instead of messing with this, can we just change the verifier to require that the alignment argument to masked_gather is nonzero? (And teach autoupgrade to fix old code.) This is just a lesser version of the same mess we used to have with other load/store operations.

If you're going to fix it this way, though, please also fix SelectionDAGBuilder.

I stared at the autoupgrade code for intrinsics. I can't find any cases of autoupgrading an intrinsic by changing the value of an argument. It looks like the interface with the LLParser and BitcodeReader don't quite work for this. I think we need to return true with NewFn = nullptr from UpgradeIntrinsicFunction. That will enable UpgradeCallsToIntrinsic to call UpgradeIntrinsicCall which will enable LLParser. BitCodeReader calls UpgradeIntrinsicCall directly. Then in UpgradeIntrinsicCall we would need to modify the argument and generate a new call with the correct arguments. But I think UpgradeCallsToIntrinsic or the BitCodeReader will then try to delete the intrinsic declaration after all calls are upgraded because they don't expect AutoUpgrade to replace a call with a call to the same intrinsic. They think the declaration should be dead after upgrading all the calls.

Update SelectionDAGBuilder as well.

efriedma accepted this revision.Jul 1 2021, 5:42 PM

LGTM

This revision is now accepted and ready to land.Jul 1 2021, 5:42 PM
This revision was landed with ongoing or failed builds.Jul 1 2021, 7:09 PM
This revision was automatically updated to reflect the committed changes.