This is an archive of the discontinued LLVM Phabricator instance.

[Clang][NFC] Clang CUDA codegen clean-up
ClosedPublic

Authored by bondhugula on Oct 21 2021, 5:16 PM.

Details

Summary

Update an instance of dyn_cast -> cast and other NFC clang-tidy fixes
for Clang CUDA codegen.

Diff Detail

Event Timeline

bondhugula created this revision.Oct 21 2021, 5:16 PM
bondhugula requested review of this revision.Oct 21 2021, 5:16 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 21 2021, 5:16 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript

Drop redundant cast.

Gentle ping to reviewers @tra @yaxunl on this NFC PR.

tra accepted this revision.Oct 25 2021, 10:48 AM

The description is a bit misleading. The dyn_cast->cast appears to be a minor part of this patch.
I'd separate clang-tidy cleanups into a separate patch or would just describe all of these changes as a clean-up. dyn_cast->cast is an NFC change here, too, considering that we're operating on a type of FunctionDecl *cudaLaunchKernelFD.

clang/lib/CodeGen/CGCUDANV.cpp
240–243

Nit: you could remove these {...} now, too.

This revision is now accepted and ready to land.Oct 25 2021, 10:48 AM
bondhugula marked an inline comment as done.Oct 25 2021, 11:46 PM

The description is a bit misleading. The dyn_cast->cast appears to be a minor part of this patch.
I'd separate clang-tidy cleanups into a separate patch or would just describe all of these changes as a clean-up. dyn_cast->cast is an NFC change here, too, considering that we're operating on a type of FunctionDecl *cudaLaunchKernelFD.

I agree. I've done the latter.

clang/lib/CodeGen/CGCUDANV.cpp
240–243

I retained this part due to the extra comment in line with LLVM style:
https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements
"We consider that readability is harmed when omitting the brace in the presence of a single statement that is accompanied by a comment (assuming the comment can’t be hoisted above the if or loop statement, see below)."

bondhugula marked an inline comment as done.
bondhugula retitled this revision from [Clang][NFC] Clang CUDA codegen: a dyn_cast -> cast instance + clang-tidy fixes to [Clang][NFC] Clang CUDA codegen clean-up.
bondhugula edited the summary of this revision. (Show Details)

Address review comments. Update commit title and summary.

@tra While on this, I also wanted to ask as to why clang cuda codegen is using an argument on the global ctor and the dtor it's generating. The argument is unused and I couldn't find any code comments to support it in either CGCUDANV.cpp or CodeGenModule.cpp. I assume there is a reason because CodeGenModule.cpp is generating an explicit bitcast and has additional utilities to convert the function type to one with no arguments. Without the argument, one could just use appendToGlobalCtors/Dtors from ModuleUtils.

tra added a comment.Oct 26 2021, 12:45 PM

@tra While on this, I also wanted to ask as to why clang cuda codegen is using an argument on the global ctor and the dtor it's generating.

It's a good question, and I don't have a good answer. It's quite possible that the parameter is not needed.

clang/lib/CodeGen/CGCUDANV.cpp
240–243

assuming the comment can’t be hoisted above the if

I think the comment can be hoisted up in this case. Up to you.

This revision was automatically updated to reflect the committed changes.
bondhugula marked an inline comment as done.

@tra While on this, I also wanted to ask as to why clang cuda codegen is using an argument on the global ctor and the dtor it's generating.

It's a good question, and I don't have a good answer. It's quite possible that the parameter is not needed.

As a result of this parameter, there appears to be a lot of code in CodegenModule.cpp to add the ctor/dtor to the global lists. All of that would disappear with a single call to appendToGlobalCtors or appendToGlobalDtors if we got rid of the argument. Perhaps the extra argument was used initially for debugging or the fact that an extra argument bumps up the stack frame and makes something else work?