This is an archive of the discontinued LLVM Phabricator instance.

[llvm][NFC] Style fixes in Inliner.cpp
ClosedPublic

Authored by mtrofin on Apr 9 2020, 3:32 PM.

Details

Summary

Function names: camel case, lower case first letter.
Variable names: start with upper letter. For iterators that were 'i',
renamed with a descriptive name, as 'I' is 'Instruction&'.

Lambda captures simplification.

Opportunistic boolean return simplification.

Diff Detail

Event Timeline

mtrofin created this revision.Apr 9 2020, 3:32 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 9 2020, 3:32 PM
dblaikie accepted this revision.Apr 9 2020, 4:59 PM

Looks good - few optional bits & pieces (the initialization's probably something I feel pretty strongly about - but naming you can take/leave as you see fit).

In general fixing names to match the LLVM naming conventions - feel free to commit that sort of thing without review, usually independent changes independently - but if you're fixing a class of bugs (like a whole bunch of functions in one class, etc) you can do it in pretty big chunks (whole class/file at a time, potentially - but don't feel like you have to fix everything or nothing).

llvm/lib/Transforms/IPO/Inliner.cpp
598–599

"I" would suffice here (in general I think of shorter variables for shorter scopes) - the LLVM style guide does provide examples with single uppercase (I thought there used to be some special case for lower case index variables - maybe that was removed with the advent of range-based for loops and such, or I'm misremembering): https://llvm.org/docs/CodingStandards.html#turn-predicate-loops-into-predicate-functions

630

Generally I'm in favor of not adding unneeded (in the sense that if the program is working as intended it won't read uninitialized values) - that way tools like MSan and the like can find bugs in this code if the program isn't working as intended.

Looks like that's the case here - InlineHistoryID is only used under the same condition (IsTriviallyDead) it's initialized. (also Clang has warnings for this too, in addition to the runtime checks)

986

Again, probably using just I is fine here. On the other hand it is a rather long loop that does some non-trivial things with this loop index, so if you prefer the longer name - I quite understand.

This revision is now accepted and ready to land.Apr 9 2020, 4:59 PM
mtrofin marked 4 inline comments as done.Apr 9 2020, 5:25 PM
mtrofin added inline comments.
llvm/lib/Transforms/IPO/Inliner.cpp
598–599

There's a name collision for 'I'.

630

My worry is maintainability - initializing is local, while making sure that code evolution doesn't lead to uninitialized value propagating isn't.

986

Also name collision, unfortunately - I also didn't like I had to cook up these long names :)

davidxl added inline comments.Apr 9 2020, 5:30 PM
llvm/lib/Transforms/IPO/Inliner.cpp
630

This is a good point. It is ok to initialize it to illegal value that can be caught by assertions or can consistently crash the program. Here is not the case: -1 is actually a valid value to indicate a state, so it is not a good idea to initialize it to it.

dblaikie added inline comments.Apr 9 2020, 5:54 PM
llvm/lib/Transforms/IPO/Inliner.cpp
598–599

Hmm - I don't see it. There's an I at 560, but that scope ends at 590 - if I is good enough for that scope, it's good enough for this one?

Also I think it's not uncommon to use J, K etc for single name index-y variables after I, but more common if the loops are tightly coupled together - would be a bit weird to use them when they're further apart.

630

Yeah, mixed opinions.

Really pedantically you could use Optional<int> which will ensure it's checked in +Asserts build, or I guess some other invalid value (like -2), though not sure how much that'd help - it'd suppress msan and make such bugs much more elusive - maybe an infinite loop later on if inlineHistoryIncludes was called with -2? Oh, maybe buffer underrun which asan would catch.

986

I see an I from 947 to 963, but not one that seems to overlap with this line/scope.

mtrofin updated this revision to Diff 256479.Apr 9 2020, 7:08 PM
mtrofin marked an inline comment as done.

iterators

mtrofin marked 8 inline comments as done.Apr 9 2020, 7:12 PM
mtrofin added inline comments.
llvm/lib/Transforms/IPO/Inliner.cpp
598–599

You are correct. I am using CLion to do the refactorings, and its naming conflict seems to be overly conservative. There's no conflict, indeed.

630

I'm removing this change from here, both because there are a few more spots I'm seeing this, and because it looks like it needs a bit more thought than appropriate for the scope of this change.

986

Yup, I'll cowardly blame the tool I used :)

mtrofin marked 2 inline comments as done.Apr 9 2020, 7:12 PM

David is thorough in the review, so no need to wait for my lgtm, though it does lgtm :)

dblaikie accepted this revision.Apr 9 2020, 8:59 PM

Reaffirming acceptance.

llvm/lib/Transforms/IPO/Inliner.cpp
598–599

Curious limitation/bug there, indeed. I wonder if there's something more powered by the Language Server Protocol and clangd that'd be more accurate in this regard...

This revision was automatically updated to reflect the committed changes.
mtrofin marked 3 inline comments as done.