PATCH: Make sure NVPTX doesn't emit symbols that aren't valid for ptxas
eliben at google.com
Mon Mar 10 13:15:22 PDT 2014
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits