llvm dev - Oct 2017 - getCacheSize() / subtarget machine id

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).

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?

* Extend MCSchedModel instead? Or even extend MCSchedModel with the 
cache size / associativity directly for this case?

My first thought was to just have an enum in the target and then check 
the CPU string (per the first bullet), but I wonder if you think there 
is a better way.

/Jonas

> 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

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