[llvm-exegesis] Ignore unsupported instructions via UnsupportedFeatures

[RKSimon]

Bugzilla Link	37602
Version	trunk
OS	Windows NT
Depends On	llvm/llvm-bugzilla-archive#37601
Blocks	#31672
CC	@adibiagio,@atrick,@legrosbuffle,@topperc,@gchatelet,@rotateright

Extended Description

Using the script detailed in http://llvm.org/docs/CommandGuide/llvm-exegesis.html is very slow as we end up testing instructions that we know aren't supported on the CPU, but we still have to wait for the JIT to fail to move on.

It would be better if:

(a) llvm-exegesis made use of the scheduler model's UnsupportedFeatures field to test if the instruction is supported and if not, early out. In particular this would help considerably with older CPUs that don't support all the AVX512 instructions......

(b) the models made use of the UnsupportedFeatures field to ignore ISAs that it doesn't support see [Bug #​37601] - for SandyBridge/Haswell where we need to "support" additional ISAs we could at least hack the field locally to match the test CPU.

[llvmbot]

Makes sense, thanks for the suggestion.

[llvmbot]

I like the concept, actually we were looking for something like this for llvm-exegesis originally, and tried using the ISEL predicates defined on instructions (and we could not because the predicates include whether the instruction is available and whether it should preferentially be used).

I have a couple issues with the UnsupportedFeatures though:

• It sounds weird to have it be a blacklist (UnsupportedFeatures) instead of a whitelist (SupportedFeatures): every time someone adds a feature, they have to go and edit old cpu models ?
• That feature actually duplicates Predicate information that is already present for ISEL (though in a separate form): def HasAVX512 : Predicate<"Subtarget->hasAVX512()">;.

What do you think about refactoring the ISEL predicates to separate into existence predicates, based on an enum value X, that would always emit the code Subtarget->hasFeature(X) (hasFeature is tablegen-generated from CPU declaration) and preference, which would be a free range string similar to what we have now ? UnsupportedFeatures could be derived from there.

[RKSimon]

I have no strong opinion, although I agree that UnsupportedFeatures seems better suited to a relatively static target as opposed to X86 which adds news ISAs every few months...

[llvmbot]

I'll try to see how much work that is.

[RKSimon]

As a stop gap solution, could we add a '-ignore-invalid' command line argument that would early out for instructions tagged to the invalid class (class idx = 0)?

It'd speed up quick run throughs but only if you specfically request it.