PATCH: Make sure NVPTX doesn't emit symbols that aren't valid for ptxas

[Eli Bendersky]

On Mon, Mar 10, 2014 at 12:26 PM, Justin Holewinski <
justin.holewinski at gmail.com> wrote:

> I had to ponder the patch a bit before I realized it was a reverse patch
> and you were adding the getSymbolName function.  I was trying to figure out
> why we had an issue in the first place if this function already existed,
> any why you were reverting it to go back to the Mangler interface. :)
>

Oops, sorry about the reverse patch. This is now committed in r203483.


>
> The patch LGTM.  I'm still concerned about collisions, but I agree that
> this is better than what we currently have.
>
> An alternative could be to implement a pre-codegen IR pass that renames
> globals to match what is representable in PTX.  This would not incur any
> additional memory cost (other than potentially increasing the size of some
> symbol names), and provide an easy way to catch (and unique) collisions.
>
> Though for correctness, the variables should only be renamed if they are
> internal.  In theory, this is currently broken because you could create a
> symbol ".foo" at the IR level and try to get its address using the CUDA
> driver API, but fail since the symbol name would really be _$_foo in the
> binary.  Perhaps we could loudly fail if an externally visible symbol would
> need mangling/uniquing, and just mangle/unique the symbol if its internal.
>

I opened PR19099 to keep track of this. A pre-codegen IR pass makes sense
to me. However, what about external symbols? In theory, they are useless if
ptxas can't assemble them anyway.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140310/fb147c0a/attachment.html>