search for: structa

Sorry, I was being an idiot and was trying to link the wrong file type. Sigh. Now I have a problem where I merge two modules each containing the same struct, one opaque and one defined, and it's not merging the two consistently. I have two, let's say %"StructA" = type opaque %"StructB" = type opaque in one module, and in the other: %"StructA" = type { i8 } %"StructB" = type { [0 x i8] } and when I link the two modules, only one is correctly defined: %"StructA" = { i8 } %"StructB" = type opaque %...

...; Sorry, I was being an idiot and was trying to link the wrong file type. Sigh. > > Now I have a problem where I merge two modules each containing the same > struct, one opaque and one defined, and it's not merging the two > consistently. I have two, let's say > > %"StructA" = type opaque > %"StructB" = type opaque > > in one module, and in the other: > > %"StructA" = type { i8 } > %"StructB" = type { [0 x i8] } > > and when I link the two modules, only one is correctly defined: > > %"StructA&q...

Bill Wendling-3 wrote: > > The error is coming from the bit-code reader. Make sure that you generated > the file with '-emit-llvm' (i.e., it's not an object file) and that it's > the binary version of the bit-code file, not the text version. > > And, llvm-gcc? really? :-) > > Is there no way that the API can generate valid bitcode? And no, not really

Hi Fraser, On 04/02/12 12:09, Fraser Cormack wrote: > > > Bill Wendling-3 wrote: >> >> The error is coming from the bit-code reader. Make sure that you generated >> the file with '-emit-llvm' (i.e., it's not an object file) and that it's >> the binary version of the bit-code file, not the text version. >> >> And, llvm-gcc? really? :-)

...1= load > 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 invaria...

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:

...ll %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);} >>> >>>...

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