llvm dev - Dec 2016 - Assign different RegClasses to a virtual, register based on 'uniform' attribute?

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