HomePhabricator

[NFCI][X86] Mark Znver3 scheduling model as complete

Authored by lebedev.ri on May 8 2021, 10:42 AM.

Description

[NFCI][X86] Mark Znver3 scheduling model as complete

To the best of my knowledge, all instructions are modelled,
and have reasonable values to them; flipping the switch
doesn't cause any diff for MCA tests, so either we're good,
or we have test coverage gaps.

I'm not really sure why no other X86 sched model is marked as complete.

Details

Event Timeline

Herald added a subscriber: Restricted Project. · View Herald TranscriptMay 8 2021, 3:07 PM

I'm not really sure why no other X86 sched model is marked as complete.

Its mainly because it doesn't improve how the model operates and people interpret "complete" in different ways (but mainly as a mark of accuracy) - its purely a way to verify that all instructions are covered by the model. But with a moving target like x86 it can cause problems - the last time I tried to use it, someone then added new x86 avx512 instructions and freaked out because the btver2 model started complaining...... We did look at trying to use the unsupported instructions tags more but I believe that caused problems as well (having to edit old cpu models to opt out of new instructions).

/llvm/lib/Target/X86/X86ScheduleZnver3.td
64

remove the fixme?

I'm not really sure why no other X86 sched model is marked as complete.

Its mainly because it doesn't improve how the model operates and people interpret "complete" in different ways (but mainly as a mark of accuracy) - its purely a way to verify that all instructions are covered by the model. But with a moving target like x86 it can cause problems - the last time I tried to use it, someone then added new x86 avx512 instructions and freaked out because the btver2 model started complaining...... We did look at trying to use the unsupported instructions tags more but I believe that caused problems as well (having to edit old cpu models to opt out of new instructions).

Right. But we already specify supported features in ProcModel, so it seems like we only need to have a list of all features,
tablegen list !intersect, and slight code reshuffling in X86.td so that the CPU features are defined before including
the sched model, so that the unsupported features can be autocomputed, and then i would think everything would work transparently..