[llvm-dev] Legal names for Functions and other Identifiers

[SANJAY SRIVALLABH SINGAPURAM via llvm-dev]

Thanks for the heads up Philip !

I did come across a strange case where LLVM allowed "%" to be a part of a
function's name. This was in the context of my patch
https://reviews.llvm.org/D33985, where I prefix the name of the source
function and the Scop ( A special kind of Region that Polly can optimize,
the name of the Scop is the name of the Region ) to the name of the PTX
kernel generated from the Scop. For e.g. The edits like the following to
<polly_src>/lib/CodeGen/PPCGCodeGeneration.cpp
<https://github.com/llvm-mirror/polly/blob/6b8cb877c2fa3ee0e626cac5811115a9c5c71b5b/lib/CodeGen/PPCGCodeGeneration.cpp#L1422>
achieves the above mentioned prefixing,

@@ -1419,7 +1438,9 @@ void GPUNodeBuilder::createKernel(__isl_take
isl_ast_node *KernelStmt) {
   Builder.SetInsertPoint(&HostInsertPoint);
   Value *Parameters = createLaunchParameters(Kernel, F, SubtreeValues);

-  std::string Name = "kernel_" + std::to_string(Kernel->id);
+  std::string Name = S.getFunction().getName().str() + "_" +
+                     S.getOrigName() + "_kernel_" +
+                     std::to_string(Kernel->id);

(Where getOrigName returns the name of the Scop before the IRBuilder
modified it)

Produces the effect,
--- a/test/GPGPU/kernel-params-only-some-arrays.ll
<https://github.com/llvm-mirror/polly/blob/6b8cb877c2fa3ee0e626cac5811115a9c5c71b5b/test/GPGPU/kernel-params-only-some-arrays.ll#L19-L20>
+++ b/test/GPGPU/kernel-params-only-some-arrays.ll
@@ -16,12 +16,12 @@
 ;        B[i] += 42;
 ;    }

-; KERNEL: ; ModuleID = 'kernel_0'
-; KERNEL-NEXT: source_filename = "kernel_0"
+; KERNEL: ; ModuleID =
'kernel_params_only_some_arrays_%or.cond---%or.end9_kernel_0'
+; KERNEL-NEXT: source_filename =
"kernel_params_only_some_arrays_%or.cond---%or.end9_kernel_0"

I don't understand how Module verification
<https://github.com/llvm-mirror/polly/blob/6b8cb877c2fa3ee0e626cac5811115a9c5c71b5b/lib/CodeGen/PPCGCodeGeneration.cpp#L1813>
was fine with this name. What are your thoughts ?


On Thu, Jun 22, 2017 at 6:14 PM Philip Pfaffe <philip.pfaffe at gmail.com>
wrote:

> Hi Sanjay,
>
> since I've seen you working with GPU code generation, one additional heads
> up: You must take care that your function names are also legal in the
> target architecture (such as PTX).
>
> While backends can legalize function names, NVPTX can't/doesn't (it can't,
> really, because kernel invocation can be done by a name string). This means
> that you mustn't have, e.g., a dot in your function name. The dot is legal
> in an LLVM identifier, but not in a ptx function name. This also is
> noteworthy because the slot tracker automatically inserts dots into
> function names for deduplication.
>
> Best,
> Philip
>
> 2017-06-22 14:34 GMT+02:00 SANJAY SRIVALLABH SINGAPURAM via llvm-dev <
> llvm-dev at lists.llvm.org>:
>
>> Thank You Chen !
>>
>> On Thu, Jun 22, 2017 at 5:21 PM 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw> wrote:
>>
>>> Perhaps you can refer to [1]. Function name should be a global one.
>>>
>>> [1] http://llvm.org/docs/LangRef.html#identifiers
>>>
>>> HTH,
>>> chenwj
>>>
>>>
>>> 2017-06-22 16:35 GMT+08:00 SANJAY SRIVALLABH SINGAPURAM via llvm-dev <
>>> llvm-dev at lists.llvm.org>:
>>>
>>>> Hello,
>>>>
>>>> I'd like to know the format a function's name must conform to. Can I be
>>>> pointed to LLVM documention that specifies the nomenclature for functions
>>>> and other Identifiers as well (%registers, ModuleID etc.) ?
>>>>
>>>> Thanks,
>>>> Sanjay
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Wei-Ren Chen (陳韋任)
>>> Homepage: https://people.cs.nctu.edu.tw/~chenwj
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170622/905c9faf/attachment.html>