search for: structb

...ry, 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 %"StructB.0" = { [0 x i8]...

...ying 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"...

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? :-)

...100]) could be an access to structS::A, structS::B, or some other random type. > Note that your TBAA DAG below does not take this into account. Yes, indeed I forgot int (*)[]. I admit my DAG was not complete you would also have to have int (*[]), void*, char* - and I am sure I forgot some more (structB::int*, structB::char*, stuctA::structB::int*, etc) - pointing to structS::A. Say you have *&S.A[0] = val; // The front-end knows you have a structS::A access. int *ptr2 = *ptr; // The front knows that you have a int(*)[] access. The front-end would generate store sa, val, !tbaa &q...

...S::A, > structS::B, or some other random type. > > Note that your TBAA DAG below does not take this into account. > > > Yes, indeed I forgot int (*)[]. I admit my DAG was not complete you would > also have to have int (*[]), void*, char* - and I am sure I forgot some more > (structB::int*, structB::char*, stuctA::structB::int*, etc) - pointing to > structS::A. > > Say you have > > *&S.A[0] = val; // The front-end knows you have a structS::A access. > int *ptr2 = *ptr; // The front knows that you have a int(*)[] access. > > > The front-end...

...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 we pick one...

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:

..."} >>> >>> 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 c...

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