This is an archive of the discontinued LLVM Phabricator instance.

[TableGen][SchedModels] Fix aliasing of SchedWriteVariant
ClosedPublic

Authored by evgeny777 on Oct 9 2020, 3:43 AM.

Details

Summary

Atm this doesn't work:

def MyWriteV : SchedWriteVariant<...>;
def : SchedAlias<WriteV, MyWriteV>;

One problem with statements above is that assertion is triggered when inferFromTransitions tries to add empty write sequence which triggers assertion in findOrInsertRW.
Another problem is that transition is always added for given scheduling class, even though that class already has InstRW for a same processor.
Patch attempts to fix both of them

Diff Detail

Event Timeline

evgeny777 created this revision.Oct 9 2020, 3:43 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 9 2020, 3:43 AM
Herald added a subscriber: pengfei. · View Herald Transcript
evgeny777 requested review of this revision.Oct 9 2020, 3:43 AM
evgeny777 updated this revision to Diff 297236.Oct 9 2020, 7:49 AM

Patch also fixes Cortex-A57 model for sxth/uxth/sxtab/uxtab instruction family. Added test case.

evgeny777 updated this revision to Diff 297254.Oct 9 2020, 9:08 AM

Reduced test case

I don't know this tablegen code very well, but I've read it through and it seems to make sense. I agree that the results look better in line with how the schedule model was written.

llvm/test/TableGen/sched-aliases.td
2

You may need REQUIRES: asserts too, to get dbg output.

48

Is ProcFoo0 needed?

llvm/test/tools/llvm-mca/ARM/A57-sxtb.s
2 ↗(On Diff #297254)

armv7 -> armv8

Is this file generated with the script? I would expect more tables at the bottom.

Can you pre-commit the file and show the differences here.

llvm/utils/TableGen/CodeGenSchedule.cpp
1678

Could we just not add them to begin with?

evgeny777 added inline comments.Oct 12 2020, 3:12 AM
llvm/test/TableGen/sched-aliases.td
48

Yes. TableGen won't add model which is not bound to any processor

evgeny777 added inline comments.Oct 12 2020, 3:13 AM
llvm/test/tools/llvm-mca/ARM/A57-sxtb.s
2 ↗(On Diff #297254)

I've reduced test case to make it easier reviewing it.
Pre-commit seems good idea. See 7102793065f2329a2fde78f32a1f2582dd89b0e7

evgeny777 updated this revision to Diff 297529.Oct 12 2020, 3:14 AM

Addressed comments

dmgreen accepted this revision.Oct 13 2020, 12:17 AM

LGTM. Cheers

llvm/test/TableGen/sched-aliases.td
48

Sure, but is the subtarget feature needed? I'm pretty sure you can remove this ProcFoo0 and have the features for "foo-0-model" empty.

llvm/test/tools/llvm-mca/ARM/A57-sxtb.s
2 ↗(On Diff #297254)

Thanks. Like it

This revision is now accepted and ready to land.Oct 13 2020, 12:17 AM
evgeny777 added inline comments.Oct 13 2020, 3:08 AM
llvm/test/TableGen/sched-aliases.td
48

Actually it's not. I've removed it in final commit. Thanks.

RKSimon added inline comments.
llvm/utils/TableGen/CodeGenSchedule.cpp
1679

@evgeny777 I'm seeing some asserts on msvc builds inside the count() on ARMGenSubtargetInfo.inc generation

This new test, sched-aliases.td, fails when I run the TableGen tests on my machine. You can see the output below. Note that this is the only test file whose RUN line specifies '-o %t' and also pipes the output to FileCheck.

Even if it were to succeed, it takes a long time to run. Is it really necessary to parse the entire AAarch64 .td file? No other test parses a complete target.

I am running on Windows.


Command Output (stdout):

$ ":" "RUN: at line 3"
$ "d:\llvm\build\bin\llvm-tblgen.exe" "-gen-instr-info" "C:\LLVM\llvm-project\llvm\test\TableGen\sched-aliases.td" "
-IC:\LLVM\llvm-project\llvm\test\TableGen/../../include" "-IC:\LLVM\llvm-project\llvm\test\TableGen/../../lib/Target
/AArch64" "-o" "D:\LLVM\Build\test\TableGen\Output\sched-aliases.td.tmp" "-debug-only=subtarget-emitter"
note: command had no output on stdout or stderr
error: command failed with exit status: 2147483651
$ "d:\llvm\build\bin\filecheck.exe" "C:\LLVM\llvm-project\llvm\test\TableGen\sched-aliases.td"

--

This revision is now accepted and ready to land.Oct 16 2020, 8:36 AM

error: command failed with exit status: 2147483651

This means "a breakpoint has been reached" error. Typically it's about hitting llvm_unreachable.
I suggest rynning the test under WinDBG (or Visual Studio debugger if you have it) so we have at least a call trace.

Even if it were to succeed, it takes a long time to run. Is it really necessary to parse the entire AAarch64 .td file? No other test parses a complete target.

Test needs InstRW<>, SchedAlias<> and other scheduler features for which you need to define instructions, register bank, e.t.c. The simplest way to implement
it was including already defined target

I will install winDBG and run the test under it.

I do wish there was a faster way to test what you're testing.

I do wish there was a faster way to test what you're testing.

Switching to ARM target (instead of AArch64) makes it twice faster. I can submit a patch for review if you like.

That would be great, thanks.

If you are happy with the mca test showing the changes, the other test could be removed if it's causing more trouble than it's worth?

Unoptimized tablegen on windows is known to be very slow. It's up to you but it may be better to create fake instructions or remove the test entirely. Parsing an entire tablegen backend for one test, even if it is a quicker one, might not be something that is great in the long run.

If you are happy with the mca test showing the changes, the other test could be removed if it's causing more trouble than it's worth?

Yeah, makes sense
Removal of the test will also fix the issue with crash, BTW

I vote for removing the test if it's not absolutely necessary.

This revision was automatically updated to reflect the committed changes.