LGTM then, obviously I trust you on the portability aspect ;-)
Mar 9 2021
Mar 8 2021
Well, it's not exactly a non functional change as it changes the API. A downstream user may need to update its code after this commit, right?
This should be ppc specific now.
Update description, and update implementation to more closely match gcc behavior.
Mar 3 2021
Mar 1 2021
@rnk : are you happy with how the patch looks now?
Same generated assembly:
Feb 26 2021
Now that https://reviews.llvm.org/D96536 landed, we can remove the assert with some more confidence.
Feb 25 2021
Feb 24 2021
The performance gain was worth doing the test update.
How did you measure this and what were the results?
Also not sure why the attempt to replace llvm:: with std:: has failed (probably some weird mix of obsolete STL with a newer patched GCC), although if it's the ABI we want, it doesn't matter.
It's better, I just still not completely get why that assert was necessary in the first place. I.e. what exact scenario is it trying to prevent? If we just want all trivially_copyable uses to be consistent across compilers, then that assert won't help (at the very least since std:: is not consistent across compiler/std versions).
Feb 23 2021
@danilaml This is certainly not complete, but that's much better than just removing an assert as proposed in https://reviews.llvm.org/D86126. Once that one is accepted, we can move forward and commit https://reviews.llvm.org/D86126
I checked the usage of this attribute, and it's indeed ignored when set to zero, so yeah, let's just not generate it in that case.
Feb 16 2021
Feb 11 2021
@danilaml I've submited https://reviews.llvm.org/D96536 that provides some replacement checks for the previous std::is_trivially_copiable <> llvm::is_trivially_copyable check. Once that one (or a similar one / a revised version) is in, I'm 100% in favor of landing that one.
Feb 10 2021
Feb 3 2021
LGTM, thanks for providing a test case!
Jan 29 2021
@rsmith I did my bet to address your comments. What do you think of current state?
Extra test cases
I'm 100% in favor of removing code, but can you explain why it's dead?
Jan 28 2021
Back to the previous version, as suggested by @rsmith . I made a few updates to NamedDecl::isReserved which get me close to the expected result, without too much overhead.
Jan 27 2021
@alexfh gentle ping?
Jan 26 2021
Would be good to have a test entry for that new pretty printer . That would also make the review easier ;-)
Jan 20 2021
Thanks @alexfh ! Should be good now.
Address doc + tool-extra issues
Jan 19 2021
As suggested by @aaron.ballman base the detection of top-level-ness on Sema::LookupName to avoid re-implementing the wheel.
ping ? This change looks harmless to me, I'd appreciate an ack though.
Jan 14 2021
Does the following mean that Python3 is now okay to use for lit?
Jan 12 2021
First review round. I'm pretty excited by this work, thanks for handling this!
Jan 11 2021
Jan 8 2021
Ignore forward declaration of tagdecl
Update codebase and testbed to reflect recent discussion.
Address some of the review
Jan 5 2021
Jan 4 2021
Rebased on main.
Rebased on main.
Dec 22 2020
Instead of pretending to be smart, just consider that if the considered decl is at the top level, then it's a top-level decl, otherwise it's not. There may be some interpretation wrt. the standard, but this seems both simple and conservative to me. It gies a few false negative, but it's a warning here, so that should be fine.
Dec 21 2020
Commited as of 5e31e226b5b2b682607a6578ff5adb33daf4fe39, I totally messed the differential revision :-)
Dec 18 2020
@siddhesh what anout the following?
Dec 17 2020
Take review into account, some extra tests suggested by @aaron.ballman and the according modification in Decl.cpp
Dec 16 2020
@rnk what do you find of this approach?
Take review into account and add more tests
Dec 15 2020
I do think it would be good for this to somehow handle macros with reserved names, since macros are one of the primary dangers of using reserved names (if I #define _Tp 0 and then later #include <vector>
When __builtin_dynamic_object_size returns a non-constant expression, it cannot be -1 since that is an invalid return value for object size
Dec 14 2020
More test cases and updated reserved isReserved()