[X86] Split vector schedule classes by vector width only as necessary

[RKSimon]

Bugzilla Link	36924
Resolution	FIXED
Resolved on	Aug 09, 2018 06:25
Version	trunk
OS	Windows NT
Blocks	#31672 #36479 #36256
CC	@adibiagio,@atrick,@legrosbuffle,@topperc,@filcab,@fhahn,@gregbedwell,@rotateright
Fixed by commit(s)	334389

Extended Description

Many targets have different schedule costs for 128/256/512-bit rr and rm versions of various SSE instructions (e.g. WriteFADD: ADDSS/ADDPS/VADDPS/VADDPSY/VADDPSZ).

Given that we're overriding them anyhow means that we will generate multiple scheduler class entries so we should probably just create separate schedule classes for them.

But, similar to [Bug #​35608], it'd be useful to avoid having to define all these classes for cases where they don't differ or are not supported - so some kind of default inheritence would be very useful.

e.g.

WriteFADD_SSE : WriteFADD
WriteFADD_AVX128 : WriteFADD
WriteFADD_AVX256 : WriteFADD
WriteFADD_AVX512 : WriteFADD

Or maybe some mechanism with SchedAlias, or could we introduce something like SchedDefaultAlias?

[RKSimon]

CC'ing Andrew/Florian/Javed who might be able to advise on this.

I was hoping that SchedAlias could be used in X86Schedule.td as a default option for classes that not all models needed and then have individual models declare a class if they needed it, but the SchedAlias always seems to act at the global level.

Should there be a way to accomplish this? Should I look at creating some kind of 'SchedDefault', similar to SchedAlias but with the functionality that I'm after?

I also tried to see if the UnsupportedFeatures field could help, but no luck.

Its a real annoyance to fill models with classes they don't require.

[atrick]

I agree with the premise, but don't fully understand the issue. Since the compiler simultaneously supports all targets in the build, you need a scheduling class entry for all unique classes across all subtargets. Within a subtarget, you should just be able to mark a scheduling class as Unsupported.

[RKSimon]

I agree with the premise, but don't fully understand the issue. Since the
compiler simultaneously supports all targets in the build, you need a
scheduling class entry for all unique classes across all subtargets. Within
a subtarget, you should just be able to mark a scheduling class as
Unsupported.

Have you examples of how to do that? The best we've been able to do is try create empty scheduler classes in the model, which results in default values (and no resource usage) - something that points to the invalid class would be better and more useful for assertions etc.

[atrick]

There's an Unsupported flag on various tablegen types that map scheduling classes to processor resources:

def : WriteRes<WriteI, []> { let Unsupported = 1; }

I think that just silences compile-time coverage checking errors and nicely documents that they aren't used by the current subtarget.

[RKSimon]

Resolving - we've now got an accepted pattern of splitting classes by vector width where necessary and implementing X86WriteResUnsupported/X86WriteResPairUnsupported (rL334389) when a model doesn't support it.

[RKSimon]

mentioned in issue #36479