llvm dev - Oct 2017 - getCacheSize() implementation (retrieving subtarget id)

Hi,

While trying to implement the SystemZTTI::getCacheSize() method, it 
became clear that a simple way of retrieving the machine ID is somehow 
missing.

It seems that the Subtarget should set a variable during initialization 
perhaps by looking at the CPU string.

I would like to hear any opinion on how this would actually be best 
implemented.

* Comparing the CPU string seems to duplicate SystemZProcessors.td in 
the sense that it would ideally be sufficient to only specify the CPU 
string once.

* Extend ProcessorModel with a "processor model ID" that the Subtarget
could later retrieve?

* Or instead extend MCSchedModel with the ID, or even store the cache 
size / assosiativity in MCSchedModel?

/ Jonas

Hi Jonas,
on PPC we store the "ID for the CPU" in what we call a
"DarwinDirective"
(the name is likely to change in the future). The idea is that the CPU
identifies itself to the Subtarget through a feature. Then you can easily
query the CPU ID through that feature.

For details, you can see `PPCTTIImpl::getCacheLineSize()`.
P.S. I imagine that after so long, you've found the solution yourself (or
come up with a different one). I am sorry, but I've been falling behind on
llvm-dev emails this fall so some have slipped by.

On Tue, Oct 17, 2017 at 4:48 PM, Jonas Paulsson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> While trying to implement the SystemZTTI::getCacheSize() method, it became
> clear that a simple way of retrieving the machine ID is somehow missing.
>
> It seems that the Subtarget should set a variable during initialization
> perhaps by looking at the CPU string.
>
> I would like to hear any opinion on how this would actually be best
> implemented.
>
> * Comparing the CPU string seems to duplicate SystemZProcessors.td in the
> sense that it would ideally be sufficient to only specify the CPU string
> once.
>
> * Extend ProcessorModel with a "processor model ID" that the
Subtarget
> could later retrieve?
>
> * Or instead extend MCSchedModel with the ID, or even store the cache size
> / assosiativity in MCSchedModel?
>
> / Jonas
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171130/e4a1c6f2/attachment.html>

Hi Nemanja,


On 2017-11-30 11:38, Nemanja Ivanovic wrote:
> Hi Jonas,
> on PPC we store the "ID for the CPU" in what we call a 
> "DarwinDirective" (the name is likely to change in the future).
The
> idea is that the CPU identifies itself to the Subtarget through a 
> feature. Then you can easily query the CPU ID through that feature.
>
> For details, you can see `PPCTTIImpl::getCacheLineSize()`.
> P.S. I imagine that after so long, you've found the solution yourself 
> (or come up with a different one). I am sorry, but I've been falling 
> behind on llvm-dev emails this fall so some have slipped by.
>
Thanks for the advice...

since this is not really urgently needed (currently not used anywhere I 
think), we decided to wait and hope for the -mtune patch to go in soon. 
Then the checking for a CPU feature (like I also thought of) like this 
would not be needed.

/Jonas

> On Tue, Oct 17, 2017 at 4:48 PM, Jonas Paulsson via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>
>     Hi,
>
>     While trying to implement the SystemZTTI::getCacheSize() method,
>     it became clear that a simple way of retrieving the machine ID is
>     somehow missing.
>
>     It seems that the Subtarget should set a variable during
>     initialization perhaps by looking at the CPU string.
>
>     I would like to hear any opinion on how this would actually be
>     best implemented.
>
>     * Comparing the CPU string seems to duplicate SystemZProcessors.td
>     in the sense that it would ideally be sufficient to only specify
>     the CPU string once.
>
>     * Extend ProcessorModel with a "processor model ID" that the
>     Subtarget could later retrieve?
>
>     * Or instead extend MCSchedModel with the ID, or even store the
>     cache size / assosiativity in MCSchedModel?
>
>     / Jonas
>
>
>
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171130/cbfd7367/attachment.html>