- User Since
- Oct 12 2014, 7:28 AM (275 w, 1 d)
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.
Feb 10 2018
@rsmith Thanks for pointing out this example. Now I see that I misunderstood the wording.
Another question is that in the provided example you say that the following line
template<typename T> A::B x<T*>; // ok!
should suppress the error of accessing private A::B. But in the wording it's said that
Feb 9 2018
Jan 23 2018
Jan 21 2018
Jan 20 2018
Sure, go ahead :)
I've checked all the test on my machine. The only one that failed was CodeGen/Generic/dwarf-md5.ll:
error: expected string not found in input ; OBJ-5: Dir MD5 Checksum File Name
but it doesn't seem to relate to the change.
Jan 19 2018
Jan 18 2018
Is it better to just add that to instcombine and forego adding the special-case with constant shift amount to instsimplify?
Yes, I think so. Thanks for indicating this.
Jan 17 2018
Jan 15 2018
As the description shows, it's absolutely right. Thanks for pointing this out.
Jan 14 2018
Thanks for the comments.
- Please upload patches with full context (-U999999)
- This needs testing coverage https://bugs.llvm.org/show_bug.cgi?id=35709#c1 notes that "(x+x+x)/x" is already handled, so maybe search for it and look how it is tested? And given that this is a generalization of that, perhaps that one is no longer needed?
The "(x+x+x)/x" case is handled because "(x+x+x)" gets turned into "mul %x, 3" and then another simplification "(x * y) / x -> y" takes place. Things like "x+x" (with power-of-2 number of terms) in turn, get simplified into "shl %x, constant". So it's not a generalization, but a particular case.
Jan 13 2018
Jul 24 2017
Jul 20 2017
Mar 30 2017
Mar 29 2017
Dec 13 2016
Nov 29 2016
@rsmith Richard, any plans to merge this or is there anything left?
Nov 28 2016
Nov 24 2016
Support gcc's __builtin_memcpy, memchr, strlen
Nov 23 2016
Nov 21 2016
Nov 20 2016
Richard, thanks, I addressed your comments.