[TableGen][SchedModels] Fix aliasing of SchedWriteVariant

[evgeny777]

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

[evgeny777]

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

[evgeny777]

Reduced test case

[dmgreen]

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

1

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

47

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 ↗

(On Diff #297254)

Could we just not add them to begin with?

[evgeny777]

llvm/test/TableGen/sched-aliases.td

47

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

[evgeny777]

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]

Addressed comments

[dmgreen]

LGTM. Cheers

llvm/test/TableGen/sched-aliases.td

47

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

[evgeny777]

llvm/test/TableGen/sched-aliases.td

47

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

[RKSimon]

llvm/utils/TableGen/CodeGenSchedule.cpp

1679 ↗

(On Diff #297806)

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

[Paul-C-Anagnostopoulos]

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"

--

[evgeny777]

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

[Paul-C-Anagnostopoulos]

I will install winDBG and run the test under it.

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

[evgeny777]

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.

[Paul-C-Anagnostopoulos]

That would be great, thanks.

[dmgreen]

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.

[evgeny777]

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

[Paul-C-Anagnostopoulos]

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

llvm/test/TableGen/sched-aliases.td

-// REQUIRES: asserts
-// REQUIRES: aarch64-registered-target
-// RUN: llvm-tblgen -gen-instr-info %s -I%p/../../include -I%p/../../lib/Target/AArch64 -o %t -debug-only=subtarget-emitter 2>&1 | FileCheck %s 
-
-// Check that we've defined scheduling classes for FMOVv2f32_ns and FMOVv2f64 for Model0
-// CHECK: InstRW: New SC [[SC:[0-9]+]]:FMOVv2f32_ns on Model0
-// CHECK: InstRW: New SC [[SC2:[0-9]+]]:FMOVv2f64_ns on Model0
-
-// Generic transition for WriteV should be defined for Model0 as well as for
-// all instructions without explicitly defined scheduling classes.
-// CHECK: Adding transition from WriteV({{[0-9]+}}) to Model0WriteV_4cyc({{[0-9]+}}) on processor indices
-// CHECK: Adding transition from WriteV({{[0-9]+}}) to Model0WriteV_2cyc({{[0-9]+}}) on processor indices
-
-// Transition from FMOVv2f64_ns should still be added for Model0,
-// even though we've defined custom scheduling class.
-// CHECK: Adding transition from FMOVv2f64_ns([[SC2]]) to Model0WriteV_4cyc({{[0-9]+}}) on processor indices
-// CHECK-NEXT: Adding transition from FMOVv2f64_ns([[SC2]]) to Model0WriteV_2cyc({{[0-9]+}}) on processor indices
-
-// Transition from FMOVv2f32_ns should not be added for Model0,
-// because custom sched class for it is defined and it's not variant.
-// CHECK-NOT: Adding transition from FMOVv2f32_ns([[SC]])
-
-include "AArch64.td"
-
-def Model0 : SchedMachineModel {
-  let CompleteModel = 0;
-}
-
-def Model0UnitV    : ProcResource<1> { let BufferSize = 0; }
-
-let SchedModel = Model0 in {
-
-def Model0WriteV_4cyc : SchedWriteRes<[Model0UnitV]> { let Latency = 4; }
-def Model0WriteV_2cyc : SchedWriteRes<[Model0UnitV]> { let Latency = 2; }
-def Model0WriteV_1cyc : SchedWriteRes<[Model0UnitV]> { let Latency = 1; }
-
-def Model0QFormPred : MCSchedPredicate<CheckQForm>;
-def Model0WriteV : SchedWriteVariant<[
-       SchedVar<Model0QFormPred, [Model0WriteV_4cyc]>,
-       SchedVar<NoSchedPred, [Model0WriteV_2cyc]>]>;
-
-def : SchedAlias<WriteV, Model0WriteV>;
-
-def : InstRW<[Model0WriteV_1cyc], (instrs FMOVv2f32_ns)>;
-def : InstRW<[WriteV], (instrs FMOVv2f64_ns)>;
-}
-
-def : ProcessorModel<"foo-0-model", Model0, []>;