- User Since
- Oct 12 2014, 7:28 AM (424 w, 4 d)
Oct 8 2022
Oct 4 2022
Anyone wants to take a look/stamp? :)
Sep 26 2022
No, it sounds like we need a proposal for [[likely_unless_the_optimizer_decides_otherwise]] -- the [[likely]] attribute was intended for always-likely optimization decisions.
Well, whatever the default behavior is chosen.
Do users have some other escape hatch to tell PGO "ignore what you think you know about this branch" so that a user who *wants* PGO to lose has some ability to do that other than "don't use PGO"?
Sep 22 2022
Apr 13 2021
Apr 10 2021
Apr 2 2021
Mar 31 2021
Aaron, Richard, thanks a lot for reviewing this!
Mar 30 2021
Address comments. Also:
- always issue a new diagnostic if size_t/ssize_t is out of range;
- prohibit numbers with 'z' suffix and non-10-radix to be interpreted as unsigned.
Mar 29 2021
Thanks Richard for taking a look!
Thanks Aaron for taking a look! Addressed the comments. I also hope it's okay to test preprocessor in the same test (test/Lexer/size_t-literal.cpp).
Mar 27 2021
Fix failing tests
Mar 25 2021
Mar 9 2021
Thanks Aaron for taking a look!
Mar 4 2021
Apr 9 2020
Thanks for taking a look!
Apr 8 2020
Apr 6 2020
Apr 4 2020
Nov 1 2019
Oct 31 2019
There is no difference in perf for GCC.
Yes, but that's because gcc still optimizes the call to noinlined function. In the common scenario which this check addresses (destructor defaulted in .cpp file) gcc is not able to optimize the call.
BTW, this very contrived benchmark shows 5x: http://quick-bench.com/sczBi_lVndKut9jOj4UofC0HYew
Did you see some significant perf improvements for Chromium?
I don't see major improvements in browser benchmarks like Speedometer, but in the Blink garbage collector, which queues destructors to be executed later, this change proved to reduce the number of them by 5%. That, in turn, reduces GC time on the main thread which is significant for latency.
Roman, thanks for reviewing and the ideas.
Oct 29 2019
Does anybody have suggestions on this?
Oct 28 2019
Thanks for the suggestions!
Roman, could you please take another look at it?
Oct 25 2019
Thanks for the suggestions! Addressed some of them.
Aug 7 2019
Aug 5 2019
Aug 2 2019
Pinging for review..
Aug 1 2019
Roman, -ast-dump shows the correct result, because the correct address space is encoded in qualifiers and is passed to Context.getAddrSpaceQualType(...) later in this function. This is why this bug is not observable from the AST. But if you try accessing real Attr* from TypeSourceInfo, you'll see this mismatch.
Jul 25 2019
Jul 24 2019
Missed that, thanks for the point!
Thanks for the comments!
Manuel, would you mind taking another look at the change please?
Jul 23 2019
Thanks for the note, updated the diff with autogenerated LibASTMatcherReference.html.
Jul 22 2019
Manuel, I left some cases which deviated from the isDerivedFrom matcher.
Nov 7 2018
@inouehrs thanks a lot, jut was granted with the access to the farm.
Oct 26 2018
@inouehrs I would be happy to work on the issue and find out what really causes the segfaults. Unfortunately, I don't have a ppc working machine, compiling clang in qemu emulating ppc took me over 3 days. Do you know of any cloud vps services based on power pc?
Oct 14 2018
Oct 10 2018
@rsmith, thanks. Le'ts see if there is a need for the command-line option down the road.
Oct 8 2018
Oct 6 2018
I've submitted an issue to the Core about the case. Presumably, it will be included in the next revision (mailing deadline of which is tomorrow).
Oct 4 2018
ClangToLLVMArgMapping is now used to get LLVM argument corresponding to 'this'.
May 12 2018
Thanks for the remarkable note. I've updated the patch and marked the first llvm::Function parameter with noalias attribute. Please notice, that this is not the only place where the position of the this pointer is assumed to always be first. As an example, another such place is here. Maybe we will have to generalize it in CGCXXABI down the road...
May 5 2018
@efriedma copy and move constructors are particular cases where the value of a constructed object may be accessed through a glvalue not obtained from 'this' pointer (but from the first arg of a ctor).
May 4 2018
I've moved setting noalias-attribute down to IR-function creation. This is needed in the context of emitting a constructor call when the definition of the constructor is not available (and clang emits an IR-constructor-declaration). @lebedev.ri @aaron.ballman I've also adjusted existing tests. There a quite a few of them, so it seems there is no reason of having a specific test case.