[llvm-dev] [cfe-dev] RFC: Devirtualization v2
Piotr Padlewski via llvm-dev
llvm-dev at lists.llvm.org
Tue Jun 19 12:51:59 PDT 2018
the patches for the proposal are waiting in the review for quite some time.
I am looking for people familiar with intrinsics, InstCombine and some
other transform passes to review these 2 patches:
As a motivation, I can say that initial measurements on LNT show nice
performance boost (80% on one microbenchmark, ~0.7% on 7zip)
pt., 30 mar 2018 o 19:33 John McCall <rjmccall at apple.com> napisał(a):
> On Mar 30, 2018, at 12:49 PM, Duncan P. N. Exon Smith <
> dexonsmith at apple.com> wrote:
> On Mar 30, 2018, at 09:39, John McCall via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> On Mar 30, 2018, at 10:36 AM, Piotr Padlewski <piotr.padlewski at gmail.com>
> Do you know any other specific situations and metadata that would require,
> or would be good if would use the same solution?
> Ah, sure. It's probably the right solution for TBAA metadata
> compatibility as well. Different compilers are likely to use different
> TBAA tag hierarchies, just because they have different rules for aliasing.
> In the absence of some way of officially declaring them compatible, we
> should assume they're incompatible and strip them during inlining. In
> fact, it's probably true that *most* annotation approaches are
> frontend-specific and should be stripped when merging information from
> different frontends.
> IIRC, the root for TBAA metadata is an identifier tag for the schema.
> This prevents incompatible TBAA schemas from interacting with each other
> without having to strip either one.
> If that's true now, great; I know the scheme has been changed a lot since
> I last looked at it. I could also be misremembering what it was when I
> last looked at it, of course.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev