search for: virtualvoidfoo

...void(%struct.A*)*, void(%struct.A*)** %vtable tail call > void%1(%struct.A* nonnull %a) ret void}!7= !{!"_ZTS1A"} > > This works well if the pointer type doesn’t change, but when it > does, devirtualization might not happen like here: > > structA { A();virtualvoidfoo();};structB : > A{ B();virtualvoidfoo();};voidg(A& > a){ a.foo(); a.foo();}voidclobber(A&);voidf() { B > b; clobber(b); g(b);} > > The other problem is that when we combine 2 instructions with > different invariant.group metadata, then...

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:

...!7= !{!"_ZTS1A"} >>> >>> This works well if the pointer type doesn’t change, >>> but when it does, devirtualization might not happen >>> like here: >>> >>> structA { A();virtualvoidfoo();};structB : >>> A{ B();virtualvoidfoo();};voidg(A& >>> a){ a.foo(); a.foo();}voidclobber(A&);voidf() >>> { B b; clobber(b); g(b);} >>> >>> The other problem is th...

2017-01-26 3:28 GMT+01:00 Richard Smith <richard at metafoo.co.uk>: > On 25 January 2017 at 15:03, Hal Finkel via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> Hi Piotr, >> >> I think makes sense. Modulo bitcasts, the invariant is identified by a >> particular pointer SSA value. Given that you can't sensibly have two >> nonequivalent

2017-01-26 15:41 GMT+01:00 Hal Finkel <hfinkel at anl.gov>: > > On 01/26/2017 06:44 AM, Piotr Padlewski wrote: > > > > 2017-01-26 3:28 GMT+01:00 Richard Smith <richard at metafoo.co.uk>: > >> On 25 January 2017 at 15:03, Hal Finkel via cfe-dev < >> cfe-dev at lists.llvm.org> wrote: >> >>> Hi Piotr, >>> >>> I think