[llvm-dev] LLVM-MCA Processor Resources ID
Andrea Di Biagio via llvm-dev
llvm-dev at lists.llvm.org
Tue Dec 15 05:05:44 PST 2020
Hi Pietro,
have a look at the Scheduler unit in llvm-mca (
http://llvm.org/doxygen/Scheduler_8h_source.html).
That's where the issue logic is.
On Tue, 15 Dec 2020 at 09:05, Pietro D'Ettole <
progettoiotpolimi2019 at gmail.com> wrote:
> Thanks for your detailed response, Andrea! It was exactly what I was
> looking for.
>
> Do you have any idea of where in llvm-mca instructions get issued? Because
> I now have to block some kind of instructions as part of my resource
> strategy.
>
> Have a nice day!
>
> Il giorno dom 13 dic 2020 alle ore 17:02 Andrea Di Biagio <
> andrea.dibiagio at gmail.com> ha scritto:
>
>> Hi Pietro,
>>
>> llvm-mca internally assigns each processor resource unit to a 64-bit mask
>> value often referred to as `processor resource mask`.
>> This convertion allows llvm-mca to speedup some set operations in the
>> ResourceManager using simple bit manipulation.
>>
>> If I remember correctly, the setCustomStrategy works on processor
>> resource masks. So you need a way to map processor resource ID to mask
>> values.
>> If you want to know how processor resource units are mapped to processor
>> resource masks, then you need to use function `computeProcResourceMasks`
>> (defined in llvm/MCA/Support.cpp).
>>
>> ```
>> void computeProcResourceMasks(const MCSchedModel &SM,
>>
>>
>> MutableArrayRef<uint64_t> Masks)
>> ```
>>
>> Array Masks is populated with processor mask values (one per each
>> processor resource unit declared by the scheduling model).
>>
>> You can visualise the mapping between resource IDs and resource masks
>> using a debug build of llvm-mca by simply passing flag
>> `-debug-only=llvm-mca`. Flag -debug` would work too. However `-debug` is
>> much more verbose as it doesn't filter out disassembler debug prints.
>>
>> Example of processor masks computed by ` computeProcResourceMasks ` for
>> -mcpu=btver2:
>>
>> Command: ` llvm-mca -debug-only=llvm-mca -mcpu=btver2 `
>>
>> ```
>> Processor resource masks:
>> [ 0] - 0x00000000000000 - InvalidUnit
>> [ 1] - 0x00000000000001 - JALU0
>> [ 2] - 0x00000000000002 - JALU1
>> [ 3] - 0x00000000004003 - JALU01
>> [ 4] - 0x00000000000004 - JDiv
>> [ 5] - 0x00000000000008 - JFPA
>> [ 6] - 0x00000000000010 - JFPM
>> [ 7] - 0x00000000000020 - JFPU0
>> [ 8] - 0x00000000000040 - JFPU1
>> [ 9] - 0x00000000008060 - JFPU01
>> [10] - 0x00000000010018 - JFPX
>> [11] - 0x00000000000080 - JLAGU
>> [12] - 0x00000000020280 - JLSAGU
>> [13] - 0x00000000000100 - JMul
>> [14] - 0x00000000000200 - JSAGU
>> [15] - 0x00000000000400 - JSTC
>> [16] - 0x00000000041800 - JVALU
>> [17] - 0x00000000000800 - JVALU0
>> [18] - 0x00000000001000 - JVALU1
>> [19] - 0x00000000002000 - JVIMUL
>> ```
>>
>> Here, each entry is a tuple { ProcResourceIdx - Mask - ProcResourceName
>> }.
>>
>> A simple lookup of that array is enough to obtain the mask values for
>> your custom strategies.
>>
>> I hope this helps.
>> -Andrea
>>
>>
>> On Sun, Dec 13, 2020 at 2:28 PM Pietro D'Ettole via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hi everyone,
>>>
>>> I need to retrieve the ID of a particular ProcResource from the
>>> processor SchedModel but I'm having problems with it.
>>> In detail, I aim to attach a custom strategy to a particular resource
>>> and to do so I thought to use the ResourceManager::setCustomStrategy()
>>> method.
>>> I've already got to define my CustomStrategy but I can't retrieve the
>>> right ResourceID.
>>> I've thought to use the MCProcResourceDesc table inside MCSchedModel,
>>> but I'm not sure it'll work.
>>>
>>> Is that a good idea? Do you have in mind a better one?
>>>
>>> Thanks!
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://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/20201215/3a4dfe21/attachment.html>
More information about the llvm-dev
mailing list