[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.
/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>
More information about the llvm-dev
mailing list