[llvm-dev] Fwd: Guidance on working with the NVIDIA GPU back-end

[CoffeeBeforeArch via llvm-dev]

---------- Forwarded message ---------
From: CoffeeBeforeArch <coffeebeforearch at gmail.com>
Date: Mon, Dec 16, 2019 at 11:49 AM
Subject: Re: [llvm-dev] Guidance on working with the NVIDIA GPU back-end
To: Dmitry Mikushin <dmitry at kernelgen.org>


Hi Dmitry,

Thanks for the response. I understand how the flow of PTX->SASS works, but
what I'm looking for guidance on is any references/insights on what would
be required to register-allocate PTX.

While this seems odd (and is for running on real hardware), simulators like
GPGPU-Sim functionally execute PTX because it is fully documented, while
the machine ISA, SASS, is not. This means that the code being used to
evaluate new architectures by researchers lacks register allocation and
even basic optimizations like hoisting loads.

Hopefully, that clears things up. Any thoughts on the best place to look to
get started with that?

All the best,

--Nick

On Mon, Dec 16, 2019 at 11:38 AM Dmitry Mikushin <dmitry at kernelgen.org>
wrote:

> Unlimited number of registers in PTX ISA means there is no any meaningful
> register allocation at all. That is, it makes no sense trying to limit
> something, which does not exist. NVPTX is lowered further by ptxas into
> physical registers, but it is out of the scope of LLVM.
>
> Kind regards,
> - Dmitry.
>
>
> пн, 16 дек. 2019 г. в 17:29, CoffeeBeforeArch via llvm-dev <
> llvm-dev at lists.llvm.org>:
>
>> Hi all,
>>
>> I'm primarily a hardware person but would like to do some
>> compiler-architecture co-design research. Are there any good references for
>> the NVPTX backend? I'd like to change that backend to have a limited number
>> of physical registers rather than an unlimited number of virtual ones (for
>> more realistic modeling in a uarch simulator).
>>
>> Being able to do register allocation and other optimizations on the
>> virtual ISA (PTX) would be incredibly useful to the research community.
>>
>> Thanks in advance,
>>
>> --Nick
>> _______________________________________________
>> 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/20191216/48a7cd24/attachment.html>