[llvm-dev] getCacheSize() implementation (retrieving subtarget id)

Jonas Paulsson via llvm-dev llvm-dev at lists.llvm.org
Thu Nov 30 06:47:37 PST 2017

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.


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

More information about the llvm-dev mailing list