This is an archive of the discontinued LLVM Phabricator instance.

[GlobalISel] Don't switch opcodes in MIRBuilder::buildInstr
ClosedPublic

Authored by rovka on Jan 4 2023, 2:38 AM.

Details

Summary

At the moment, MachineIRBuilder::buildInstr may build an instruction
with a different opcode than the one passed in as parameter. This may
cause confusion for its consumers, such as CSEMIRBuilder, which will
memoize the instruction based on the new opcode, but will search
through the memoized instructions based on the original one (resulting
in missed CSE opportunities). This is all the more unpleasant since
buildInstr is virtual and may call itself recursively both directly
and via buildCast, so it's not always easy to follow what's going on.

This patch simplifies the API of MachineIRBuilder so that the
buildInstr method does the least surprising thing (i.e. builds an instruction
with the specified opcode) and only the convenience buildX methods
(buildMerge etc) are allowed freedom over which opcode to use. This
can still be confusing (e.g. one might write a unit test using
buildBuildVectorTrunc but instead get a plain G_BUILD_VECTOR), but
at least it's explained in the comments.

In practice, this boils down to 3 changes:

  • buildInstr(G_MERGE_VALUES) will no longer call itself with

G_BUILD_VECTOR or G_CONCAT_VECTORS; this functionality is moved to
buildMerge and replaced with an assert;

  • buildInstr(G_BUILD_VECTOR_TRUNC) will no longer call itself with

G_BUILD_VECTOR; this functionality is moved to buildBuildVectorTrunc
and replaced with an assert;

  • buildInstr(G_MERGE_VALUES) will no longer call buildCast and will

instead assert if we're trying to merge a single value; no change is
needed to buildMerge since it was already asserting more than one
source operand.

This change is NFC for users of the buildX methods, but users that
call buildInstr with relaxed parameters will have to update their code
(such instances will hopefully be easy to find thanks to the asserts).

Diff Detail

Event Timeline

rovka created this revision.Jan 4 2023, 2:38 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 4 2023, 2:38 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
rovka requested review of this revision.Jan 4 2023, 2:38 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 4 2023, 2:38 AM
foad accepted this revision.Jan 4 2023, 3:23 AM
foad added a subscriber: foad.

This patch simplifies the API of MachineIRBuilder so that the
buildInstr method does the least surprising thing (i.e. builds an instruction
with the specified opcode) and only the convenience buildX methods
(buildMerge etc) are allowed freedom over which opcode to use.

I like this!

Does this patch actually fix any missed CSE opportunities?

I wonder if we could get rid of buildMerge altogether, in favour of separate buildMergeValues / buildConcatVectors / buildBuildVector functions.

This revision is now accepted and ready to land.Jan 4 2023, 3:23 AM
rovka added a comment.Jan 4 2023, 3:52 AM

This patch simplifies the API of MachineIRBuilder so that the
buildInstr method does the least surprising thing (i.e. builds an instruction
with the specified opcode) and only the convenience buildX methods
(buildMerge etc) are allowed freedom over which opcode to use.

I like this!

Does this patch actually fix any missed CSE opportunities?

No, we also need to add G_BUILD_VECTOR to CSE.

I wonder if we could get rid of buildMerge altogether, in favour of separate buildMergeValues / buildConcatVectors / buildBuildVector functions.

We already have buildBuildVector and buildConcatVectors and they seem to have a decent number of uses. I haven't really audited all the uses of buildMerge to see if it would be onerous to replicate the checks for vectors everywhere :) I could have a look and send a follow-up patch if the existing uses aren't too sloppy.

arsenm accepted this revision.Jan 4 2023, 7:42 AM
arsenm added a subscriber: arsenm.

We should have a separate buildMergeValues and buildMerge could use a less confusing name

rovka added a comment.Jan 5 2023, 1:04 AM

We should have a separate buildMergeValues and buildMerge could use a less confusing name

Ah, naming... I'll see what I can do :)

Thanks for the reviews!

This revision was automatically updated to reflect the committed changes.