This revision was automatically updated to reflect the committed changes.
Closed by commit rL303488: [Devirtualization] insert placement new barrier with
-O0 (authored by Prazek).
Changed prior to commit:
https://reviews.llvm.org/D32401?vs=96313&id=99667#toc
Repository:
rL LLVM
https://revi
mehdi_amini accepted this revision.
mehdi_amini added a comment.
This revision is now accepted and ready to land.
LGTM.
https://reviews.llvm.org/D32401
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/lis
rjmccall added a comment.
In https://reviews.llvm.org/D32401#759223, @Prazek wrote:
> Is everyone ok with sending this patch?
As long as this continues to be an opt-in optimization, go ahead and do your
research project, I suppose.
https://reviews.llvm.org/D32401
_
Prazek added a comment.
Is everyone ok with sending this patch?
https://reviews.llvm.org/D32401
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Prazek added a comment.
In https://reviews.llvm.org/D32401#738513, @rjmccall wrote:
> In https://reviews.llvm.org/D32401#735127, @Prazek wrote:
>
> > In https://reviews.llvm.org/D32401#734921, @rjmccall wrote:
> >
> > > I continue to be really uncomfortable with the entire design of this
> > > o
mehdi_amini added a comment.
I tend to agree with @rjmccall on the principle. Howerever:
> The optimization design seems to rely on anticipating every case that should
> disable the optimization, hence this patch adding special-case logic to the
> frontend, and the 3 other patch
I believe this
rjmccall added a comment.
In https://reviews.llvm.org/D32401#735127, @Prazek wrote:
> In https://reviews.llvm.org/D32401#734921, @rjmccall wrote:
>
> > I continue to be really uncomfortable with the entire design of this
> > optimization, which appears to miscompile code by default, but as long
Prazek added a comment.
In https://reviews.llvm.org/D32401#734921, @rjmccall wrote:
> I continue to be really uncomfortable with the entire design of this
> optimization, which appears to miscompile code by default, but as long as
> nobody's suggesting that we actually turn it on by default, I
rjmccall added a comment.
I continue to be really uncomfortable with the entire design of this
optimization, which appears to miscompile code by default, but as long as
nobody's suggesting that we actually turn it on by default, I guess it can be
your little research-compiler playground. It mi
Prazek added a comment.
In https://reviews.llvm.org/D32401#734870, @rjmccall wrote:
> Won't you have the exact same problem when LTO'ing with code that wasn't
> compiled with strict v-table pointers?
No, because we fire error when combining module compiled with and without
StrictVtablePoint
mehdi_amini added a comment.
> To not break LTO with different optimizations levels, we should insert the
> barrier regardles of optimization level.
What do you mean by "break"? Is it a correctness issue?
https://reviews.llvm.org/D32401
___
cfe-co
rjmccall added a comment.
Won't you have the exact same problem when LTO'ing with code that wasn't
compiled with strict v-table pointers?
https://reviews.llvm.org/D32401
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/
Prazek created this revision.
Herald added a subscriber: mehdi_amini.
To not break LTO with different optimizations levels, we should insert
the barrier regardles of optimization level.
https://reviews.llvm.org/D32401
Files:
lib/CodeGen/CGExprCXX.cpp
Index: lib/CodeGen/CGExprCXX.cpp
===
13 matches
Mail list logo