similar to: [RFC] Clean up the way we store optional Function data

I've done some measurements on this. The test program I have just calls Function::Create(), F->setPersonalityFn(), and then F->eraseFromParent() in a loop 2^20 times. Results: pre-patch --- min: 1.10s max: 1.13s avg: 1.11s post-patch --- min: 1.26s max: 1.35s avg: 1.29s So we expect to lose 0.2 seconds per 1 million functions (with personality functions) in a

Here is a WIP patch as promised: http://reviews.llvm.org/D13829 It uses a hungoff uselist to store optional data as needed. Some early objections from Duncan: - An extra one-time malloc() is required to set personality functions. - We get and set personality functions frequently. This patch introduces a level of indirection which slows the common case down. Is this overhead

On Tue, Apr 4, 2017 at 12:36 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > On 2017-Apr-04, at 12:12, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >>

On 10/10/13 10:43 AM, Hongxu Chen wrote: > Hi, this question might be a bit silly: apart from the language > reference(http://llvm.org/docs/LangRef.html#switch-instruction) page, are > there additional rules for a regular llvm frontend to generate llvm IRs? > > There are a few cases that I got from clang/llvm-gcc/dragonegg when > compiling *C* source code into llvm IR: > >

On Fri, Oct 11, 2013 at 12:06 AM, John Criswell <criswell at illinois.edu>wrote: > On 10/10/13 10:43 AM, Hongxu Chen wrote: > >> Hi, this question might be a bit silly: apart from the language >> reference(http://llvm.org/**docs/LangRef.html#switch-**instruction<http://llvm.org/docs/LangRef.html#switch-instruction>) >> page, are >> there additional rules

Hi, this question might be a bit silly: apart from the language reference(http://llvm.org/docs/LangRef.html#switch-instruction) page, are there additional rules for a regular llvm frontend to generate llvm IRs? There are a few cases that I got from clang/llvm-gcc/dragonegg when compiling *C* source code into llvm IR: 1. It seems that there is ONLY ONE ReturnInst(and NO InvokeInst) for such llvm

Hi, I was trying to remove some old code that handles ReturnInsts with more than 1 operand -- see attached patch -- when I stumbled across test/Assembler/aggregate-return-single-value.ll: define { i32 } @fooa() nounwind { ret i32 0 } ... define [1 x i32] @fooc() nounwind { ret i32 0 } Is there really any need to handle these odd cases, where the type of the value being returned doesn't