This fixes parameter names mismatch in anonymous functions.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
60,050 ms | x64 debian > libFuzzer.libFuzzer::minimize_crash.test |
Event Timeline
Thank you for the patch. I'm OK with the fix in principle, but would like to check if we could make parameter name generation common for both function signature and the parameter symbol.
llvm/lib/Target/NVPTX/NVPTXISelLowering.cpp | ||
---|---|---|
2624 | While this does seem to produce correct argument name, at least for the test example, I'm not convinced it's the best way to handle this. The issue is that we're still generating parameter symbol name here separately from where it gets generated for the function signature. Off the top of my head I do not recall where it happens and I didn't have time to track it down yet. We should attempt to make sure that the name is guaranteed to be generated using the same algorithm. E.g. via a common helper function. | |
llvm/test/CodeGen/NVPTX/anonymous-fn-param.ll | ||
4 | The patch description and the test should be a bit more specific describing what the problem is. AFAICT, the problem is that there's currently a mismatch between the parameter name we generate in the function signature (__unnamed_1_param_0) and the name we use when we refer to the parameter in the body of the function (_param_0). https://godbolt.org/z/dMEKe1anG |
Nice! I like that there's just one way to determine parameter name now.
llvm/test/CodeGen/NVPTX/anonymous-fn-param.ll | ||
---|---|---|
12–14 | I'd move it down to the second function. When possible, checks should be placed close to the code that we're checking. |
- Update the test according to review notes.
llvm/test/CodeGen/NVPTX/anonymous-fn-param.ll | ||
---|---|---|
12–14 | Done. |
While this does seem to produce correct argument name, at least for the test example, I'm not convinced it's the best way to handle this. The issue is that we're still generating parameter symbol name here separately from where it gets generated for the function signature. Off the top of my head I do not recall where it happens and I didn't have time to track it down yet.
We should attempt to make sure that the name is guaranteed to be generated using the same algorithm. E.g. via a common helper function.