llvm dev - Oct 2010 - [LLVMdev] Status of PTX Backend

I read on the archives that a PTX back-end was discussed around August and I
see that some initial code has been checked into LLVM trunk.  What is the
status of this project?  Is it being actively worked on?

I am ultimately interested in using LLVM for GPU code
optimization/generation and am very interested in this particular project.

-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101006/77a2505d/attachment.html>

Hi Justin,

I am upstreaming the PTX backend.
My plan is to have a working prototype (that mean you may compile
non-trivial code with some workarounds) by the end of this year or by
January 2011.
I hope I could catch up next release of LLVM (version 2.9), so I will
adjust my plan according to the release schedule once it is announced.

Regards,
Che-Liang

On Wed, Oct 6, 2010 at 11:16 PM, Justin Holewinski
<justin.holewinski at gmail.com> wrote:
>
> I read on the archives that a PTX back-end was discussed around August and
I
> see that some initial code has been checked into LLVM trunk.  What is the
> status of this project?  Is it being actively worked on?
> I am ultimately interested in using LLVM for GPU code
> optimization/generation and am very interested in this particular project.
>
> --
>
> Thanks,
> Justin Holewinski
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>

Hi,

The PTX backend we developed (CBackend approach, does not use the target 
independent code generator) is already more advanced.
An older version is published here: 
http://sourceforge.net/projects/llvmptxbackend/

We recently eliminated a bug which increased the number of required 
registers per thread. Surprisingly, without that bug the generated code 
is already comparable to code generated by the official nvcc copiler.  
Of cause the nvcc compiler is superior in a lot of cases, however only 
by a small margin. And there are even cases(e.g. a phong surface shader) 
where our PTX backend is faster, without any particular optimization! It 
seems like the NVIDIA driver does a good job at late optimizations liker 
register allocation etc. I can give you some numbers if you are intrested.
I'll push the newest version of the backend to sourceforge during the 
next days.

What kind of optimizations are you planning to do? If you want to apply 
high level (on llvm bitcode) optimizations, you can start with our PTX 
backend and shwitch over to the new backend approach later on (If it 
turns out that the new approach is really faster).

best, Helge



Am 06.10.2010 17:39, schrieb Che-Liang Chiou:
> Hi Justin,
>
> I am upstreaming the PTX backend.
> My plan is to have a working prototype (that mean you may compile
> non-trivial code with some workarounds) by the end of this year or by
> January 2011.
> I hope I could catch up next release of LLVM (version 2.9), so I will
> adjust my plan according to the release schedule once it is announced.
>
> Regards,
> Che-Liang
>
> On Wed, Oct 6, 2010 at 11:16 PM, Justin Holewinski
> <justin.holewinski at gmail.com>  wrote:
>> I read on the archives that a PTX back-end was discussed around August
and I
>> see that some initial code has been checked into LLVM trunk.  What is
the
>> status of this project?  Is it being actively worked on?
>> I am ultimately interested in using LLVM for GPU code
>> optimization/generation and am very interested in this particular
project.
>>
>> --
>>
>> Thanks,
>> Justin Holewinski
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>