search for: vtable1

On Fri, Jul 31, 2015 at 3:53 PM, Philip Reames <listmail at philipreames.com> wrote: > > Quoting from the google doc: "If we don’t know definition of some > function, we assume that it will not call @llvm.invariant.group.barrier(). > " > This part really really bugs me. We generally try to assume minimal > knowledge of external functions (i.e. they can do

...rn value from foo or a global variable, we know that any SSA value created inside foo isn't relevant. We should end up a with two loads of the vtable using the same SSA value and the same invariant.group metadata. The later can be forwarded from the former without issue right? %a = ...; %vtable1 = load %a + Y !invariant.group !0 %foo1 = load %vtable1 + X, !invariant.group !1 call %foo1(%a) %vtable2 = load %a + Y !invariant.group !0 <-- Per state rules, this value forwards from previous vtable load %foo2 = load %vtable2 + X, !invariant.group !1 call %foo2(%a) Philip -------------- ne...

Hi all, I would like to propose a new way clang would decorate vtable loads in order to handle devirtualization better. I've added *llvm-dev* also, because this can start a discussion about changing invariant.group to just invariant. PDF version of this RFC can be found here: https://drive.google.com/file/d/0B72TmzNsY6Z8ZmpOUnB5dDZfSFU/view?usp=sharing Background: Initial old design: