[llvm-dev] getCacheSize() / subtarget machine id

[Matthias Braun via llvm-dev]

> On Oct 17, 2017, at 8:04 AM, Jonas Paulsson via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi,
> 
> while implementing SystemZTTI:getCacheSize(), it became clear that there really isn't a simple way to just ask the Subtarget for the current subtarget machine model. I was thinking like something of an enum that would also reflect the subtarget series (and would allow >= and similar operations).

What exactly do you mean by machine model? There is MCSubtargetInfo::getSchedModel().

If you look at AArch64, ARM, X86 then you'll see that they use subtarget features to initialize an XXXProcFamily member in their subtargetinfo. AArch64Subtarget::initializeProperties() then has a switch to set a number of properties based on that for example.

> 
> I would like to ask what the ideas are on how this should be done best. Some thoughts:
> 
> * Just comparing the CPU string during initializaition is possible (and perhaps simple and good enough), but ideally it would be better not to do this, as those strings are already in the (SystemZ)Processors.td file.
> 
> * Extend ProcessorModel with a "processor model ID" that the subtarget could later retrieve?
I like the idea of having tablegen generating the enum instead of the odd way we use subtarget features for this today.

> 
> * Extend MCSchedModel instead? Or even extend MCSchedModel with the cache size / associativity directly for this case?
Possible. One thing though is that the MCSchedModel is a static const datastructure, so targets wouldn't have the flexibility to report anything else than what comes with the scheduling model. That said I don't know whether we actually need this flexibility.


As we are on the topic of per-cpu information: While it is easy enough to encode a bunch of processor specifics with the boolean subtarget features. And the `initializeProperties()` thing works well enough for integer values. I find functions like AArch64InstrInfo::isAsCheapAsAMove() and shouldScheduleAdjacent() are somewhat spaghetti code which I believe could be cleaned up with a mechanism where we could specify CPU specific subclasses of SubtargetInfo and put the implementations of those functions in a processor specific class. It would be more code, but I believe it would be cleaner and we can still factor out common pieces and put them into the base class.

- Matthias