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

[Eli Bendersky]

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

>
> On Mon, Mar 10, 2014 at 4:15 PM, Eli Bendersky <eliben at google.com> wrote:
>
>>
>>
>>
>> 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.
>>
>
> Right, if a symbol is internal, we can mangle/unique it.  But if its
> externally-defined or externally-visible, we can't do anything to it.  It's
> not perfect, but its likely the best we can do given the current
> constraints in the PTX assembler.
>

Just to examine the possibilities in a bit more detail: since the
problematic characters in question are "." and "@", and these can't be part
of a valid CUDA program, then as you pointed out, they can only sneak in
via LLVM IR. This means NVPTX is involved. So there are two options:

1. Don't mangle external symbols that contain forbidden chars.
2. Do mangle all symbols -- external and internal.

(1) means that a PTX file simply won't compile, so it will be unusable
completely. (2) means that the PTX file will compile, but if the external
symbol is explicitly referenced, it won't be found, because its name has
changed. This can still be worked around by manually mangling the name
given to the driver API, right?

Yes, this is ugly and horrible and all, but it's not like we've never seen
manually-mangled C++ names appear in C interfaces (to access stuff where
"extern C" was emitted for some reason). The point is, this can be made to
work *somehow*, as opposed to the alternative -- (1) which means things
won't work at all.

What am I missing?

Naturally, this all can go away if ptxas grows an ability to do some
rudimentary quoting :)

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