This is an archive of the discontinued LLVM Phabricator instance.

[clang] Eliminate TypeProcessingState::trivial.
ClosedPublic

Authored by mboehme on Apr 14 2022, 4:52 AM.

Details

Summary

This flag is redundant -- it's true iff savedAttrs is empty.

Querying savedAttrs.empty() should not take any more time than querying the
trivial flag, so this should not have a performance impact either.

I noticed this while working on https://reviews.llvm.org/D111548.

Diff Detail

Event Timeline

mboehme created this revision.Apr 14 2022, 4:52 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 14 2022, 4:52 AM
mboehme requested review of this revision.Apr 14 2022, 4:52 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 14 2022, 4:52 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
aaron.ballman added inline comments.Apr 14 2022, 11:06 AM
clang/lib/Sema/SemaType.cpp
168–169

Isn't the same true for this variable? It seems like:

trivial == savedAttrs.empty()
hasSavedAttrs == !savedAttrs.empty()

mboehme added inline comments.Apr 18 2022, 11:50 PM
clang/lib/Sema/SemaType.cpp
168–169

That's what I also thought at first -- but the situation for hasSavedAttrs is a bit more complicated. It gets set whenever saveDeclAttrs() is called, even if it doesn't actually end up saving any attributes (i.e. if spec.getAttributes() is empty).

hasSavedAttrs is then used to prevent any further calls to saveDeclSpecAttrs() from doing anything:

// Don't try to save them multiple times.
if (hasSavedAttrs) return;

Conceivably, spec _might_ have had attributes added to it in the meantime -- not sure? It might be OK to just replace this logic with if (!savedAttrs.empty()) return; -- but I'm not familiar enough with how this code gets used and therefore decided it would be better not to change it. Can you give additional input on this?

aaron.ballman added inline comments.Apr 19 2022, 8:38 AM
clang/lib/Sema/SemaType.cpp
168–169

I have the impression that is an oversight in the code rather than an intentional behavior. I think it may be okay to replace the logic with !savedAttrs.empty() as well; if you do that, do you get any test failures? (If you do, then that's a sign something else might be going on.)

mboehme marked an inline comment as done.Apr 20 2022, 2:48 AM
mboehme added inline comments.
clang/lib/Sema/SemaType.cpp
168–169

I just tried:

// Don't try to save them multiple times.
if (!savedAttrs.empty()) return;

I didn't get any test failures.

Of course, this isn't proof that this is _really_ OK, but it's an indication.

You know this code better than I do, so I would defer to you: How do you think I should proceed? Should I eliminate hasSavedAttrs too?

aaron.ballman added inline comments.Apr 20 2022, 5:51 AM
clang/lib/Sema/SemaType.cpp
168–169

I think you should eliminate it -- I don't think the behavior here was intentional (based on what I can tell from the code).

mboehme updated this revision to Diff 425145.Apr 26 2022, 1:20 AM
mboehme marked an inline comment as done.

Eliminate hasSavedAttrs as well.

mboehme marked an inline comment as done.Apr 26 2022, 1:21 AM
mboehme added inline comments.
clang/lib/Sema/SemaType.cpp
168–169

OK -- done!

aaron.ballman accepted this revision.Apr 26 2022, 7:39 AM

LGTM, thank you for the cleanup!

This revision is now accepted and ready to land.Apr 26 2022, 7:39 AM
This revision was automatically updated to reflect the committed changes.
mboehme marked an inline comment as done.