similar to: [LLVMdev] Creating global data with [ 0 x ... ] type

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 hope we could even eliminate some unused virtual functions from the final binary. — Mehdi > On Jan 27, 2016, at 10:29 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Peter, > > Pete (Cooper, CC'ed) had a

Hi all, I'd like to make the following proposal to implement an optimization called virtual constant propagation. ==Introduction== After enabling control flow integrity protection in Chromium, we have observed an unacceptable performance regression in certain critical layout microbenchmarks. Profiling [0] revealed that the cause of the regression was a large number of virtual calls, each

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

On Fri, Mar 4, 2016 at 2:48 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Mon, Feb 29, 2016 at 1:53 PM, <> wrote: >> >> @A_vtable = {i8*, i8*, i32, i32} {0, @A::rtti, @A::f - (@A_vtable + 16), >> @A::g - (@A_vtable + 16)} >> > > There's a subtlety about this aspect of the ABI that I should call > attention to. The virtual function

Hi all, I'd like to propose an IR extension that allows the inbounds keyword to be attached to indices in a getelementptr constantexpr. By placing the inbounds keyword on an index, any pointer derived from the getelementptr outside of the bounds of the element referred to by that index, other than the pointer one past the end of the element, shall be treated as a poison value. The main

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 call the relative ABI. That bug gives more

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

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

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 issue of inheritance: Suppose I have

(+Chris, since I assume he wrote this policy - and, as I said in my previous email, I wouldn't mind seeing some justification or just seeing the rule go away & drop the anchors I added previously (or, if we're going to keep it, we could add more anchors & actually get to the point where we're -Wweak-vtable clean & enable that warning)) On Wed, Jun 12, 2013 at 1:44 PM,

> On Mar 4, 2016, at 2:48 PM, Peter Collingbourne via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Mon, Feb 29, 2016 at 1:53 PM, < <mailto:>> wrote: > @A_vtable = {i8*, i8*, i32, i32} {0, @A::rtti, @A::f - (@A_vtable + 16), @A::g - (@A_vtable + 16)} > > There's a subtlety about this aspect of the ABI that I should call attention to. The virtual function

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, I'm trying to create a constant (named) struct and store a pointer to it in another struct using the C Api (and the llvm-fs bindings). As a contrived example, this is what I want to do: %A = type { %VTable* } %VTable = type { void (%A*)*, void (%A*)* } define void @main(%A* %a) { entry: %0 = getelementptr inbounds %A* %a, i32 0, i32 0 ; [type=%VTable**] %2 = somehow make a

I tried to build LLVM with 'gcc-4.8.1 -flto', and when linking unittest programs, I got the following error: /tmp/cc8pMk84.ltrans30.ltrans.o:(.data.rel.ro._ZTIN4llvm2cl15OptionValueCopyISsEE[_ZTIN4llvm2cl15OptionValueCopyISsEE]+0x10): undefined reference to `typeinfo for llvm::cl::GenericOptionValue'

I would start from using module-level metadata. An IR extension might be a good idea once we show that - the proposed indirect call protection mechanism is efficient and useful, and - there are other use cases for the IR extension. --kcc On Wed, Jan 28, 2015 at 2:57 AM, Sean Silva <chisophugis at gmail.com> wrote: > Is there any way to accomplish this that doesn't require

Forgot to cc the list. > >----- Forwarded Message ---- >From: Samuel Crow <samuraileumas at yahoo.com> >To: James Williams <junk at giantblob.com> >Sent: Mon, January 31, 2011 4:27:45 PM >Subject: Re: [LLVMdev] Compile function with limited set of registers? Jump to >another function? > > >Hi James, > > >If you're looking for a way to

On 3 May 2018, at 22:09, David Zarzycki via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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

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

Hi all, I would like to propose a mechanism that allows IR modules to co-operatively build a pointer set corresponding to addresses within a given set of globals. The specific use case I have in mind is to provide a mechanism 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

So, bitset would be a property that means : globals with the same name will append on a string of bits in the order in which they appear, and it's the job of the front end to make sure the correct order is followed in every unit, so that linking does the right job in every corner case? Could that be used for efficient global boolean flags, like LLVM's options? Even if you don't need