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

[Jonas Paulsson via llvm-dev]

Hi Matthias,


>> 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().
I meant model as a particular subtarget.
> 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.
Yes, this is basically what I first did and didn't like: Checking for 
particular processor features that are present / absent and then 
deducing the subtarget.
>> 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.
I agree. Intuitively it makes sense to me to order the enums per the 
time line of the processor generations. That way, one could for instance 
on SystemZ say >= z13 to mean z13 and z14. I guess if this is a good 
idea, there should be some ID defined somewhere so that the subtargets 
get the right ordering?
>> * 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.
Is there any benefit from putting this in MCSchedModel? It seems that 
this enum (+ values) could be just generated in ...GenSubtargetInfo.inc?
>
>
> 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.
That seems to be another context where it is really just best to 
directly know the subtarget.

/Jonas