This is an archive of the discontinued LLVM Phabricator instance.

[MC][Tablegen] Allow models to describe the retire control unit for llvm-mca.
ClosedPublic

Authored by andreadb on Apr 4 2018, 7:57 AM.

Details

Summary

This patch adds the ability to describe properties of the hardware retire control unit.

Tablegen class RetireControlUnit has been added for this purpose (see TargetSchedule.td).

A RetireControlUnit specifies the size of the reorder buffer, as well as the maximum number of opcodes that can be retired every cycle.

A zero (or negative) value for the reorder buffer size means: "the size is unknown". If the size is unknown, then llvm-mca defaults it to the value of field SchedMachineModel::MicroOpBufferSize.
A zero or negative number of opcodes retired per cycle means: "there is no restriction on the number of instructions that can be retired every cycle".

Models can optionally specify an instance of RetireControlUnit. There can only be up-to one RetireControlUnit definition per scheduling model.

Information related to the RCU (RetireControlUnit) is stored in (two new fields of) MCExtraProcessorInfo.
llvm-mca loads that information when it initializes the DispatchUnit / RetireControlUnit (see Dispatch.h/Dispatch.cpp).

This patch fixes PR36661.

Please let me know if okay to commit

-Andrea

Diff Detail

Event Timeline

andreadb created this revision.Apr 4 2018, 7:57 AM
courbet added inline comments.Apr 5 2018, 2:32 AM
tools/llvm-mca/Dispatch.cpp
262

Can we get rid of the MaxRetirePerCycle ctor parameter ? Is there any reason why the user would override this ?

tools/llvm-mca/Dispatch.h
194

Any reason for this to be in a separate function ? What about moving the ctor definition to the cpp file and inlining the code ?
Else when reading the ctor definition here it's not obvious that AvailableSlots might be overridden in initialize().

andreadb added inline comments.Apr 5 2018, 2:46 AM
tools/llvm-mca/Dispatch.cpp
262

The original idea was to let users override the retire-per-cycle.
However, with this patch, the max-retire-per-cycle can now be set via tablegen.

That being said, most processors don't provide a max-retire-per-cycle. This patch would only fix the BtVer2 model.
So, I am tempted to keep the flag for now (although, I don't have a strong opinion about it). Alternatively, I can commit a separate patch that removes the flag, and the rebase this patch. What do you think?

tools/llvm-mca/Dispatch.h
194

No reason. I will move the constructor to the cpp file.

Why did the tests change ? I thought that this change would not impact tests.

tools/llvm-mca/Dispatch.cpp
262

I'm pretty sure that I would stick to tablegen-specified models as a user. And if you're developing you own processor, I hope that you have your own tools :) So the flag does not sound that useful to me given that it makes a bit harder to understand this code.
I don't have a strong opinion though, so feel free to keep the flag if i'ts useful to you.

Why did the tests change ? I thought that this change would not impact tests.

It does have an impact on the retire stage.

On BtVer2, the retire throughput is 2 instructions per cycle. It does affect the timeline at least.

tools/llvm-mca/Dispatch.cpp
262

That's a good point (especially if you have your own tools).
It could have been used to experiment/play with the RCU (with SMT processors we might emulate a different retire throughput).
That being said, the argument is a bit weak. SMT introduces other issues related to the partitioning of resources which cannot be fully tweaked via flags.

If okay for you, I am going to commit a change that removes the flag and updates the docs in preparation for this patch. Then I rebase this patch.

andreadb updated this revision to Diff 141142.Apr 5 2018, 6:04 AM

Patch updated.

Addressed review comments.

andreadb marked 3 inline comments as done.Apr 5 2018, 6:30 AM
andreadb added inline comments.
tools/llvm-mca/Dispatch.cpp
262

I went ahead and removed that flag at r329274.

RKSimon accepted this revision.Apr 5 2018, 7:57 AM

LGTM with a couple of minors

include/llvm/MC/MCSchedule.h
176

These comments repeat a lot of what is said in TargetSchedule.td - make the comments briefer here?

tools/llvm-mca/Dispatch.h
269–273

Are you confident that we won't need llvm::MCSubtargetInfo again anytime soon?

This revision is now accepted and ready to land.Apr 5 2018, 7:57 AM

Thanks Simon.

include/llvm/MC/MCSchedule.h
176

I will simplify the comment.

tools/llvm-mca/Dispatch.h
269–273

Ideally, all the information needed by the dispatch logic should be accessible through the scheduling model. I may be wrong, but I don't think that we will need it again.

This revision was automatically updated to reflect the committed changes.
benhamilton added inline comments.
llvm/trunk/utils/TableGen/SubtargetEmitter.cpp
616 ↗(On Diff #141168)

Looks like this broke the build:

http://green.lab.llvm.org/green//job/clang-stage1-cmake-RA-incremental/47722/consoleFull#-172429723349ba4694-19c4-4d7e-bec5-911270d8a58c

/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm/utils/TableGen/SubtargetEmitter.cpp:616:9: error: no matching function for call to 'max'
        std::max(ReorderBufferSize, RCU->getValueAsInt("ReorderBufferSize"));
        ^~~~~~~~

P8077

I am going to fix it now.
I guess I should have used int64_t ...