Displaying 5 results from an estimated 5 matches for "_zts1b".
Did you mean:
_zts1s
2011 Dec 09
1
[LLVMdev] Implementing devirtualization
...x i8*] [i8* null, i8*
bitcast ({ i8*, i8*, i8* }* @_ZTI1B to i8*), i8* bitcast (i32
(%class.B*)* @_ZN1B3fooEv to i8*), i8* bitcast (i32 (%class.A*)*
@_ZN1A3gooEv to i8*), i8* bitcast (i32 (%class.A*, %class.A*)*
@_ZN1AplERS_ to i8*)]
@_ZTVN10__cxxabiv120__si_class_type_infoE = external global i8*
@_ZTS1B = linkonce_odr constant [3 x i8] c"1B\00"
@_ZTVN10__cxxabiv117__class_type_infoE = external global i8*
@_ZTS1A = linkonce_odr constant [3 x i8] c"1A\00"
@_ZTI1A = linkonce_odr unnamed_addr constant { i8*, i8* } { i8*
bitcast (i8** getelementptr inbounds (i8**
@_ZTVN10__cxxabiv11...
2016 Nov 01
2
Ambiguity in !tbaa metadata?
...y stated today, though.
For completeness, here is the C++ source that was used to generate the
IR above:
struct A { char f; };
struct B { A a; };
struct C { int f; };
int f(B *b, C *c, int *i) {
return b->a.f + c->f + *i;
}
and the metadata was:
!2 = !{!3, !5, i64 0}
!3 = !{!"_ZTS1B", !4, i64 0}
!4 = !{!"_ZTS1A", !5, i64 0}
!5 = !{!"omnipotent char", !6, i64 0}
!6 = !{!"Simple C++ TBAA"}
!7 = !{!8, !9, i64 0}
!8 = !{!"_ZTS1C", !9, i64 0}
!9 = !{!"int", !5, i64 0}
!10 = !{!9, !9, i64 0}
-- Sanjoy
2011 Dec 09
0
[LLVMdev] Implementing devirtualization
On Thu, Dec 8, 2011 at 2:11 PM, Vitor Luis Menezes <vitor at utexas.edu> wrote:
> We've got the following test case:
>
>
> class A {
> public:
> int x;
> A(int x) : x(x) {}
> int hoo() {return 4;}
> virtual int foo() {return x;}
> virtual int goo() {return foo()+10;}
> virtual int operator+(A &a) {
> return x + a.x;
> }
> };
2011 Dec 08
2
[LLVMdev] Implementing devirtualization
We've got the following test case:
class A {
public:
int x;
A(int x) : x(x) {}
int hoo() {return 4;}
virtual int foo() {return x;}
virtual int goo() {return foo()+10;}
virtual int operator+(A &a) {
return x + a.x;
}
};
class B : public A {
public:
B(int x) : A(x) {}
int hoo() {return 2;}
virtual int foo() {return A::foo()*2;}
};
int main() {
A* a = new A(1);
2017 Jan 20
4
RFC: Emitting empty invariant group for vtable loads
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: