[llvm-dev] Assign different RegClasses to a virtual, register based on 'uniform' attribute?
Zeng Xlous via llvm-dev
llvm-dev at lists.llvm.org
Thu Dec 22 19:08:27 PST 2016
On 2016年12月22日 15:37, via llvm-dev wrote:
> Send llvm-dev mailing list submissions to
> llvm-dev at lists.llvm.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> or, via email, send a message with subject or body 'help' to
> llvm-dev-request at lists.llvm.org
>
> You can reach the person managing the list at
> llvm-dev-owner at lists.llvm.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of llvm-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: llvm/cuda: Indentify kernel functions and optimizations
> (Jingyue Wu via llvm-dev)
> 2. Re: llvm/cuda: Indentify kernel functions and optimizations
> (Gurunath Kadam via llvm-dev)
> 3. Re: Assign different RegClasses to a virtual register based
> on 'uniform' attribute? (Ruiling Song via llvm-dev)
> 4. Re: Assign different RegClasses to a virtual register based
> on 'uniform' attribute? (Ruiling Song via llvm-dev)
> 5. Postdoc Positions - LLVM for High-Performance Computing
> (Hal Finkel via llvm-dev)
> 6. struct bitfield regression between 3.6 and 3.9 (using -O0)
> (Phil Tomson via llvm-dev)
> 7. Re: DeclarationName and the StringRef.
> (Umesh Kalappa via llvm-dev)
> 8. convert load with load from getElementPtr
> (Varun Patil via llvm-dev)
> 9. Re: convert load with load from getElementPtr
> (Mehdi Amini via llvm-dev)
> 10. Re: Correct way to pass int128 from LLVM to C++ function
> (MSVC) (Stefan de Bruijn via llvm-dev)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 21 Dec 2016 15:13:40 -0800
> From: Jingyue Wu via llvm-dev <llvm-dev at lists.llvm.org>
> To: Gurunath Kadam <gurunath.kadam at gmail.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] llvm/cuda: Indentify kernel functions and
> optimizations
> Message-ID:
> <CAMROOrHSNcJaD36617RGwMJBn1nfT2VKgrELUYeFX-itoKP0SA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> https://github.com/llvm-mirror/llvm/blob/652375a8cc49615de31fd9d424753795059185b6/lib/Target/NVPTX/NVPTXUtilities.h#L58
>
> Does this solve your problem?
>
> On Wed, Dec 21, 2016 at 2:29 PM, Gurunath Kadam via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> I am trying to instrument CUDA kernel functions only (llvm-3.9.0).
>>
>> Is there a way to identify cuda kernel functions?
>>
>> I see that in llvm IR for CUDA has nvvm annotations section, where kernel
>> functions are identified for NVPTX usage. I can parse the whole IR for this
>> kernel metadata and then proceed, but this is very clumsy.
>>
>> Other way is to work with cuda-device-only IR. But then I am not sure how
>> to run this cuda-only-IR, as this contains cuda-device specific code and
>> not rest of the host-device code.
>>
>> In NVPTXBaseInfo.h, the function attributes are defined, along
>> with PROPERTY_ISKERNEL_FUNCTION. How can this be used to identify the
>> kernel function?
>>
>> Thanks.
>>
>> -Gurunath
>>
>> _______________________________________________
>> 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/20161221/61525ae8/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 21 Dec 2016 18:35:11 -0500
> From: Gurunath Kadam via llvm-dev <llvm-dev at lists.llvm.org>
> To: Jingyue Wu <jingyue at google.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] llvm/cuda: Indentify kernel functions and
> optimizations
> Message-ID:
> <CAGvue2_VdTrTXAn-i4njspM2HEr4Katm5RTk5Hs5EK6LeJ+urw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Jingyue,
>
> Thank should work! :)
>
> Also, next time I will check the available resources in NVPTX before
> posting here!
>
> Thanks.
>
> -Gurunath
>
> On Wed, Dec 21, 2016 at 6:13 PM, Jingyue Wu <jingyue at google.com> wrote:
>
>> https://github.com/llvm-mirror/llvm/blob/652375a8cc49615de31fd9d4247537
>> 95059185b6/lib/Target/NVPTX/NVPTXUtilities.h#L58
>>
>> Does this solve your problem?
>>
>> On Wed, Dec 21, 2016 at 2:29 PM, Gurunath Kadam via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> I am trying to instrument CUDA kernel functions only (llvm-3.9.0).
>>>
>>> Is there a way to identify cuda kernel functions?
>>>
>>> I see that in llvm IR for CUDA has nvvm annotations section, where kernel
>>> functions are identified for NVPTX usage. I can parse the whole IR for this
>>> kernel metadata and then proceed, but this is very clumsy.
>>>
>>> Other way is to work with cuda-device-only IR. But then I am not sure how
>>> to run this cuda-only-IR, as this contains cuda-device specific code and
>>> not rest of the host-device code.
>>>
>>> In NVPTXBaseInfo.h, the function attributes are defined, along
>>> with PROPERTY_ISKERNEL_FUNCTION. How can this be used to identify the
>>> kernel function?
>>>
>>> Thanks.
>>>
>>> -Gurunath
>>>
>>> _______________________________________________
>>> 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/20161221/ac2aad13/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 22 Dec 2016 08:02:37 +0800
> From: Ruiling Song via llvm-dev <llvm-dev at lists.llvm.org>
> To: Matt Arsenault <arsenm2 at gmail.com>
> Cc: James Molloy via llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] Assign different RegClasses to a virtual
> register based on 'uniform' attribute?
> Message-ID:
> <CAAv59xRGZ_84MXN=69gBj=TZEfXBBMtHWiOyhzYZ7hV7_+JtOg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2016年12月21日星期三，Matt Arsenault <arsenm2 at gmail.com> 写道：
>> On Dec 21, 2016, at 10:26, Ruiling Song <ruiling.song83 at gmail.com> wrote:
>>
>>
>> 2016-12-20 22:14 GMT+08:00 Tom Stellard <tom at stellard.net>:
>>> On Tue, Dec 20, 2016 at 11:00:09AM +0800, Ruiling Song wrote:
>>>> Hi,
>>>>
>>>> I am working on a new LLVM target for Intel GPU, which also has same
> kind
>>>> of scalar/vector register classes used in AMDGPU target. Like for a i32
>>>> virtual register, it will be held in scalar register if its value is
>>>> uniform across a wavefront/warp, otherwise it will be in a vector
> register.
>>>> Does AMDGPU already done this? I read the code, but I didn't figure
> out how
>>>> to do this. Anybody has idea on this?
>>>>
>>> In the AMDGPU backend we select everything we can to scalar
>>> instructions, and then after instruction selection, we move
>>> non-uniform values to the vector ALU. This is done by
>>> the SIFixSGPRCopiesPass, which relies heavily on
>>> SIInstrInfo::moveToVALU().
>> Hi Tom,
>>
>> I take a look at the code, it looks like a good idea. It really helps me
> a lot. Thanks Tom! I have a question for the code, why it only pass
> copy-like instructions as TopInst to moveToALU()? Is there any special
> reason to do like this? I thought that iterating through all the MIs and
> fix regClass if needed would be ok. Am I thinking it too simple?
>> - Ruiling
>>> -Tom
>>>
>>>> - Ruiling
>>
>>
>>
>> --
>> - Ruiling
>>
>> The instruction selector will insert these copies to satisfy the register
> operand constraints, so by finding all users (and users of users) of the
> illegal copies you find the same thing.
> Only checking copy-like MIs and their further user sounds more reasonable.
> if iterating through all MIs and checking all the MIs' the Src&Dst register
> class to find out instructions that need to fix, which is what I previously
> thought, would just waste some compile time.
>
> The instruction set is different, so we’re really replacing the
> instructions and not exactly just changing the register classes.
>> I think this process logically makes sense, moving things to vector as
> forced. However I’m uncertain if this is the best approach. I’ve debated
> going the other direction and selecting everything to vector instruction,
> and having an optimization pass move parts to scalars.
> I don't know what makes you thinking about the change. Is "the other
> direction" more safe because it only optimize known pattern? Or do you ever
> meet some situation that you cannot handle it smart using current solution?
> I will do some try in my target, may be we can have some further discussion
> after I know more about LLVM on this.
> - Ruiling
> This is what the AMD compiler does. There are different trade offs, but one
> advantage is you immediately have something resembling a legal program to
> begin with.
>> -Matt
More information about the llvm-dev
mailing list