search for: vtables

Using relative offsets applies to more than just vtables. It would do wonders for constant strings too. -- Sean Silva On Mon, Feb 29, 2016 at 1:53 PM, Peter Collingbourne via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Hi all, > > I'd like to make a proposal to implement the new vtable ABI described in > PR26723, which I'll...

Hi all, I'd like to make a proposal to implement the new vtable ABI described in PR26723, which I'll call the relative ABI. That bug gives more details and justification for that ABI. The user interface for the new ABI would be that -fwhole-program-vtables would take an optional value indicating which aspects of the program have whole-program scope. For example, the existing implementation of whole-program vcall optimization allows external code to call into translation units compiled with -fwhole-program-vtables, but does not allow external code to...

Hi all, I’ve been working on a Java-esque object-oriented language Bolt that targets LLVM IR. I’m agonisingly close to getting a virtual table working, and was hoping one of you could point out the gap in my understanding. I’ve linked the C++ code snippets relevant to the vtable below. Example IR generated (partially displayed below):

Dear Mailing List, This might sound unconventional, but I am trying to access a C++ objects vtable to pass as an argument to a function call for a library function I created. Creating & inserting a function call at the correct location in LLVM is done. I have learned that C++ objects are represented as struct types. But I'm just not quite sure how to get at the vtable pointer within,

Hi Peter, Thanks for your answer! > On Jan 28, 2016, at 10:17 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > Hans wrote: >> (and start-up time if we can drop the vtables and >> void the dynamic relocations). > > On Thu, Jan 28, 2016 at 09:15:05AM -0800, Mehdi Amini wrote: >> Hi, >> >> I just thought about another use case: VTable compression. >> If you know that an entry in the Vtable is never used, just remove it! >> I’d...

...d without CFI, and that we expect to see better performance >> from a general implementation that targets all virtual functions. >> >> ==User interface== >> To instruct the compiler to assume that all type hierarchies are closed, a >> user can pass the -fwhole-program-vtables flag. The -fwhole-program-vtables >> flag requires the -flto flag to also be specified. >> >> Of course, there may be some type hierarchies that are not entirely closed, but >> the underlying assumption is that most hierarchies will not be. To support open >> hierarch...

...xtend ThinLTO to allow a bitcode module to embed another bitcode module containing summary information. The purpose of doing so is to support CFI and whole-program devirtualization optimizations under ThinLTO. Overview The CFI and whole-program devirtualization optimizations work by transforming vtables according to the class hierarchy. For example, if a class A has two derived classes B and C, CFI will lay out the vtables for A, B and C consecutively, so that clients can check that a vtable refers to a derived class of A by performing arithmetic on the virtual function pointer. For more details,...

...nism for a C++ program to efficiently verify (at each call site) that a vtable pointer is in the set of valid vtable pointers for the class or its derived classes. One way of doing this is for a toolchain component to build, for each class, a bit set that maps to the memory region allocated for the vtables, such that each 1 bit in the bit set maps to a valid vtable for that class, and lay out the vtables next to each other, to minimize the total size of the bit sets. Call sites would perform a range check followed by a load of the appropriate bit from the bit set. To give a concrete example, suppose...

Hi, Can someone help me with how to dump the vtable and the vptr addresses within it? Thanks, Dami -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170529/5dc7e058/attachment.html>

...hat these numbers are from a regular LTO build without CFI, and that we expect to see better performance from a general implementation that targets all virtual functions. ==User interface== To instruct the compiler to assume that all type hierarchies are closed, a user can pass the -fwhole-program-vtables flag. The -fwhole-program-vtables flag requires the -flto flag to also be specified. Of course, there may be some type hierarchies that are not entirely closed, but the underlying assumption is that most hierarchies will not be. To support open hierarchies the user can also specify the path to a b...

...ence to `typeinfo for llvm::cl::GenericOptionValue' This seems to be due to the (mis-)use of "anchor" methods in CommandLine. I commited r183830, with a removal of the anchor method for GenericOptionValue, which solved my link problem. Also, the commit didn't change the number of vtables, as measured by: find -name \*.o | xargs nm -C | grep 'V vtable' | grep OptionValue | wc The current LLVM developer policy text regarding "anchor" methods is: "If a class is defined in a header file and has a vtable (either it has virtual methods or it derives from classe...

A question about the layout of structs: I decided to make my vtables out of structs rather than arrays. In other words, instead of being a table of opaque pointers, I decided to individually declare each entry with the correct type for that method. I figure that the various optimizers could do a better job if I preserve the type info. OK, so we come to the issu...

...should've been. (& that removing the anchor was simply a workaround to avoid linking to an implementation file...) > I > commited r183830, with a removal of the anchor method for > GenericOptionValue, which solved my link problem. Also, the commit didn’t > change the number of vtables, as measured by: > > > > find -name \*.o | xargs nm -C | grep 'V vtable' | grep OptionValue | wc Where did you run this command? Across the whole LLVM build? It's possible that, even with a weak vtable, you only get one copy of it if, as you mention below, you only create...

...lso to allow bitcode objects to be shared between links of targets with differing valid LTO visibility. This utilizes the !vcall_visibility metadata added for Dead Virtual Function Elimination. The summary of changes required are (these are described in more detail later): 1) When -fwhole-program-vtables is specified, always insert type test assumes for virtual calls, and additionally add !vcall_visibility metadata to vtable definitions (which will be summarized in the ThinLTO index). 2) At LTO link time, apply hidden LTO visibility to vtable definition vcall_visibility metadata (or summary) when...

...(at each call site) that a vtable >> pointer is in the set of valid vtable pointers for the class or its >> derived >> classes. One way of doing this is for a toolchain component to build, for >> each >> class, a bit set that maps to the memory region allocated for the vtables, >> such that each 1 bit in the bit set maps to a valid vtable for that class, >> and lay out the vtables next to each other, to minimize the total size of >> the bit sets. Call sites would perform a range check followed by a load of >> the appropriate bit from the bit set....

Hello, In an effort to help LLVM-style projects save memory, I’ve been toying with some macros that provide an alternative to C++ vtables that use LLVM-style RTTI design patterns instead. Is this something that LLVM or sub-projects think is worth pursuing? Or are the macros below too ugly/problematic? Feedback would be appreciated. Thanks, Dave //===- llvm/Support/VTable.h - LLVM-style vtables ---------------*- C++ -*-===// // /...

Hello xapian users, The server I'm compiling on is a little odd. SunOS on a sun4 architecture. Fails when linking, gives the following, memcpy 0x10 /usr/local/gcc-3.3.2/lib/./libstdc++.a(ctype.o) ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status *** Error code 1 make: Fatal error:

Hi all, I've only pasted the last few lines of where the Xapian build fails below (the entire piece is 6639 lines long). I didn't get any warnings regarding zlib or libuuid from configure, so I'm assuming I have compatible versions. I am using libtool 2.2.6b, GNU ld 2.20.2010303. I know gcc 3.3.2 is a little behind the times, but I see the the documentation the minimum requirement is

...is in the set of valid vtable pointers for the class or its > > >> derived > > >> classes. One way of doing this is for a toolchain component to build, > for > > >> each > > >> class, a bit set that maps to the memory region allocated for the > vtables, > > >> such that each 1 bit in the bit set maps to a valid vtable for that > class, > > >> and lay out the vtables next to each other, to minimize the total > size of > > >> the bit sets. Call sites would perform a range check followed by a > load of &g...

...program to efficiently verify (at each call site) that a vtable > pointer is in the set of valid vtable pointers for the class or its derived > classes. One way of doing this is for a toolchain component to build, for each > class, a bit set that maps to the memory region allocated for the vtables, > such that each 1 bit in the bit set maps to a valid vtable for that class, > and lay out the vtables next to each other, to minimize the total size of > the bit sets. Call sites would perform a range check followed by a load of > the appropriate bit from the bit set. > > To gi...