PATCH: implement printf call lowering in the NVPTX backend

Eli Bendersky eliben at google.com
Fri Mar 28 16:25:24 PDT 2014


On Fri, Mar 28, 2014 at 3:56 PM, Yuan Lin <yulin at nvidia.com> wrote:

> Eli,
>
>
>
> I am sure you are aware this is a very specific pass for translating calls
> to printf functions for the NVPTX backend with current existing CUDA driver
> implementation.
>


Hi Yuan, thanks for your comments.

I'm note sure I fully understand. A lot in the NVPTX backend is tightly
coupled with the driver, which further lowers the PTX into something. Are
you suggesting it would be better to create this coupling between the
front-end and the driver?


>
>
> With your patch, the NVPTX backend won’t be able to handle the input IR
> that contains a user defined ‘printf’ function.
>

The pass checks whether printf is *defined* in the module (note that this
is the final, linked IR module before code generation). If yes, it doesn't
do its thing, so IR containing a user-defined 'printf' will work. I can add
a tests case for that upstream just to be on the safe side.


>  It will also cause trouble for implementation that implements ‘printf’ as
> an external llibrary call.
>

Can you clarify -- is there PTX-level linking here? NVPTX gets the fully
linked LLVM IR and code-gens it. At this stage I believe there are no
external library calls, only PTX syscalls.


>
>
> Instead of adding this pass to the NVPTX backend, it would be better to do
> the translation in the compiler module (e.g. clang or other front-ends)
> that generates the LLVM IR for the NVPTX backend.
>

So you're suggesting to expose vprintf as a formal part of the NVVM IR
specification (http://docs.nvidia.com/cuda/nvvm-ir-spec/index.html)?
Because it's not currently there.

Neither is printf, to be fair. But printf is at least documented & known at
the CUDA level.

In other words, when you expect someone to target libNVVM for some
alternative front-end language (let's say compiling Matlab or whatever
other language), how can he print anything? Are you going to expose vprintf
as a libNVVM API?

As long as it's not exposed in this way, it makes more sense to me to make
it a NVPTX explicit pass, because conceptually only NVPTX "knows" what
vprintf is (in the same way it "knows" how PTX instructions should look).
And this is then a viable way for someone to develop an open-source
toolchain for CUDA based on Clang and LLVM with the NVPTX backend.

Eli










>
>
>
> *From:* Eli Bendersky [mailto:eliben at google.com]
> *Sent:* Wednesday, March 26, 2014 9:51 AM
> *To:* llvm-commits at cs.uiuc.edu; Justin Holewinski; Justin Holewinski
> *Cc:* Yuan Lin; Jingyue Wu
> *Subject:* PATCH: implement printf call lowering in the NVPTX backend
>
>
>
> Hello,
>
>
>
> This patch implements lowering of the printf call to the vprintf syscall
> in the NVPTX backend. It is implemented as a target-specific IR pass that
> runs before codegen. The pass builds the required data structure from the
> varargs to pass to the vprintf calls.
>
>
>
> Tests (IR to IR, and IR to PTX) included.
>
>
>
> PTAL,
>
> Eli
>
>
>  ------------------------------
>  This email message is for the sole use of the intended recipient(s) and
> may contain confidential information.  Any unauthorized review, use,
> disclosure or distribution is prohibited.  If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies
> of the original message.
>  ------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140328/bb3a5718/attachment.html>


More information about the llvm-commits mailing list