This is an archive of the discontinued LLVM Phabricator instance.

[MC] Store number of implicit operands in MCInstrDesc. NFC.
ClosedPublic

Authored by foad on Jan 20 2023, 7:15 AM.

Details

Summary

Combine the implicit uses and defs lists into a single list of uses
followed by defs. Instead of 0-terminating the list, store the number
of uses and defs. This avoids having to scan the whole list to find the
length and removes one pointer from MCInstrDesc (although it does not
get any smaller due to alignment issues).

Remove the old accessor methods getImplicitUses, getNumImplicitUses,
getImplicitDefs and getNumImplicitDefs as all clients are using the new
implicit_uses and implicit_defs.

Diff Detail

Event Timeline

foad created this revision.Jan 20 2023, 7:15 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 20 2023, 7:15 AM
foad requested review of this revision.Jan 20 2023, 7:15 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 20 2023, 7:15 AM
arsenm added a subscriber: arsenm.Jan 20 2023, 7:33 AM
arsenm added inline comments.
llvm/include/llvm/MC/MCInstrDesc.h
212

Could these be reordered to avoid the alignment padding?

foad added inline comments.Jan 20 2023, 7:36 AM
llvm/include/llvm/MC/MCInstrDesc.h
212

You could avoid some internal padding but I don't think you could make the struct any smaller overall.

I didn't worry too much about the exact layout of this struct until the end of the whole stack of patches.

arsenm accepted this revision.Jan 20 2023, 7:41 AM
arsenm added inline comments.
llvm/include/llvm/MC/MCInstrDesc.h
212

Probably could force the 64-bit fields to 4-byte alignment and see how compile time benchmarks look

This revision is now accepted and ready to land.Jan 20 2023, 7:41 AM
foad added inline comments.Jan 20 2023, 7:45 AM
llvm/include/llvm/MC/MCInstrDesc.h
212

The final layout is 24 bytes of which 22 are used, so it didn't seem worth playing that kind of trick.

arsenm added inline comments.Jan 20 2023, 7:59 AM
llvm/utils/TableGen/InstrInfoEmitter.cpp
909–910

Does this really need to generate a copy of vector for every instruction/

barannikov88 added inline comments.
llvm/utils/TableGen/InstrInfoEmitter.cpp
1187

I understand that the intent is to reduce code duplication, but appending Defs to Uses looks awkward.
Can it use llvm::concat_range?

foad added inline comments.Jan 23 2023, 7:51 AM
llvm/utils/TableGen/InstrInfoEmitter.cpp
909–910

Did you have an alternative in mind? Change getValueAsListOfDefs to append to an existing vector?

Or the EmittedLists map key could be a pair of vectors instead of a vector - but I have no idea what that would do to the overall efficiency of this code.

Would it help to move from Defs instead of copy from it?

barannikov88 added inline comments.Jan 23 2023, 8:04 AM
llvm/utils/TableGen/InstrInfoEmitter.cpp
909–910

ArrayRef Uses = II->ImplicitUses; should work.

barannikov88 added inline comments.Jan 23 2023, 8:11 AM
llvm/utils/TableGen/InstrInfoEmitter.cpp
909–910

PrintDefList accepts const std::vector<Record*> &; that should be changed to ArrayRef too (otherwise the vector will be implicitly constructed).
Unfortunately, ArrayRef::operator std::vector<T>() is not marked as explicit to catch this.

foad added inline comments.Jan 23 2023, 12:12 PM
llvm/utils/TableGen/InstrInfoEmitter.cpp
909–910

I've changed this code to use II->ImplicitUses and II->ImplicitDefs (thanks!) in rG2eef8759152c7aba837addd8e90fda73c9c1f63e and rebased.

barannikov88 added inline comments.Jan 23 2023, 12:39 PM
llvm/utils/TableGen/InstrInfoEmitter.cpp
117

This is confusing.
The name suggests it prints defs, the parameter name is Uses, but it really prints both.

1187

Never mind, the suggestion won't work since EmittedLists is keyed by std::vector, i.e. it has to be constructed anyway.

barannikov88 added inline comments.Jan 23 2023, 12:41 PM
llvm/utils/TableGen/InstrInfoEmitter.cpp
120–122

(Nit) could also use structured bindings: for (auto [Idx, Op] : enumerate(Ops))

foad added inline comments.Jan 23 2023, 12:42 PM
llvm/utils/TableGen/InstrInfoEmitter.cpp
117

Yes, but it goes away in D142218 :)

This revision was landed with ongoing or failed builds.Jan 24 2023, 1:23 PM
This revision was automatically updated to reflect the committed changes.
foad marked an inline comment as done.Jan 24 2023, 1:24 PM
gulfem added a subscriber: gulfem.Jan 24 2023, 2:11 PM

BOLT seems like using the removed getImplicitUses method(). That's why we started seeing the following failure:

[3786/4445](41) Building CXX object tools/bolt/lib/Passes/CMakeFiles/LLVMBOLTPasses.dir/LivenessAnalysis.cpp.o
In file included from /opt/s/w/ir/x/w/llvm-llvm-project/bolt/lib/Passes/LivenessAnalysis.cpp:9:
/opt/s/w/ir/x/w/llvm-llvm-project/bolt/include/bolt/Passes/LivenessAnalysis.h:145:30: error: no member named 'getImplicitUses' in 'llvm::MCInstrDesc'
      for (auto I = InstInfo.getImplicitUses(),
                    ~~~~~~~~ ^
/opt/s/w/ir/x/w/llvm-llvm-project/bolt/include/bolt/Passes/LivenessAnalysis.h:146:30: error: no member named 'getImplicitUses' in 'llvm::MCInstrDesc'
                E = InstInfo.getImplicitUses() + InstInfo.getNumImplicitUses();
                    ~~~~~~~~ ^
/opt/s/w/ir/x/w/llvm-llvm-project/bolt/include/bolt/Passes/LivenessAnalysis.h:146:59: error: no member named 'getNumImplicitUses' in 'llvm::MCInstrDesc'
                E = InstInfo.getImplicitUses() + InstInfo.getNumImplicitUses();

https://logs.chromium.org/logs/fuchsia/buildbucket/cr-buildbucket/8791052753995739793/+/u/clang/build/stdout

foad added a comment.Jan 24 2023, 2:16 PM

BOLT seems like using the removed getImplicitUses method(). That's why we started seeing the following failure:

[3786/4445](41) Building CXX object tools/bolt/lib/Passes/CMakeFiles/LLVMBOLTPasses.dir/LivenessAnalysis.cpp.o
In file included from /opt/s/w/ir/x/w/llvm-llvm-project/bolt/lib/Passes/LivenessAnalysis.cpp:9:
/opt/s/w/ir/x/w/llvm-llvm-project/bolt/include/bolt/Passes/LivenessAnalysis.h:145:30: error: no member named 'getImplicitUses' in 'llvm::MCInstrDesc'
      for (auto I = InstInfo.getImplicitUses(),
                    ~~~~~~~~ ^
/opt/s/w/ir/x/w/llvm-llvm-project/bolt/include/bolt/Passes/LivenessAnalysis.h:146:30: error: no member named 'getImplicitUses' in 'llvm::MCInstrDesc'
                E = InstInfo.getImplicitUses() + InstInfo.getNumImplicitUses();
                    ~~~~~~~~ ^
/opt/s/w/ir/x/w/llvm-llvm-project/bolt/include/bolt/Passes/LivenessAnalysis.h:146:59: error: no member named 'getNumImplicitUses' in 'llvm::MCInstrDesc'
                E = InstInfo.getImplicitUses() + InstInfo.getNumImplicitUses();

https://logs.chromium.org/logs/fuchsia/buildbucket/cr-buildbucket/8791052753995739793/+/u/clang/build/stdout

Sorry. Can you please try converting this code to the for (I : implicit_uses()) style? If not I will do it tomorrow.

Amir added a subscriber: Amir.Jan 24 2023, 3:17 PM

@foad: the build error was flagged by pre-merge checks:
https://buildkite.com/llvm-project/premerge-checks/builds/132223#0185e040-b660-4955-8454-915e5c5800fa/6-10847

I'll fix it up but please don't ignore the signal as it breaks BOLT in upstream.

foad added a comment.Jan 25 2023, 1:48 AM

@foad: the build error was flagged by pre-merge checks:
https://buildkite.com/llvm-project/premerge-checks/builds/132223#0185e040-b660-4955-8454-915e5c5800fa/6-10847

I'll fix it up but please don't ignore the signal as it breaks BOLT in upstream.

Thanks and sorry, will try to pay more attention to the pre-merge checks.