similar to: [LLVMdev] inline functions

Hi Julien, > I have an LLVM bitcode file, with several functions in it. > I'm trying to inline these functions as much as possible, so that I can > obtain a big single function. > There is opt -inline, but it is not sufficient. mark your functions with the alwaysinline attribute. Ciao, Duncan.

Hi, We want to apply the deepest possible inlining to the target code. Looks like builder.Inliner = createFunctionInliningPass(2000); does the sufficient inlining, but what would be the best value for threshold here? Apparently, builder.Inliner = createFunctionInliningPass(numeric_limits<int>::max()); gives less inlining, that 2000. Thanks, - D.

Hi Dmitry, > We want to apply the deepest possible inlining to the target code. Looks like you could give every function the alwaysinline attribute. Ciao, Duncan.

On 10/21/11 7:18 AM, Julien Henry wrote: > Hi all, > > I have an LLVM bitcode file, with several functions in it. > I'm trying to inline these functions as much as possible, so that I can > obtain a big single function. > There is opt -inline, but it is not sufficient. There an option in opt to change the inlining threshold. Do opt --help-hidden to find it. It might help.

Hi! I have a llvm::Module that references an external function and a second mdoule that implements the function. The implementation consists of only one instruction. How can I explicitly inline this function? -Jochen

On Tue, Feb 2, 2010 at 11:40 AM, Jochen Wilhelmy <j.wilhelmy at arcor.de> wrote: > Hi! > > I have a llvm::Module that references an external function > and a second mdoule that implements the function. > The implementation consists of only one instruction. > How can I explicitly inline this function? > > -Jochen > >

> You can use Clang to compile source to bitcode: > > clang -c hello.c -emit-llvm -o hello.bc > Yes. My problem is to automatically create .bc files with ./configure && make. Ideally, when compiling a project like "grep", I'd like to obtain a single .bc file containing all the project's functions, instead of the grep binary executable. I already tried

2011/4/26 Duncan Sands <baldrick at free.fr> > Hi Nabila, > > > where did the "noalias" attribute and "tail call" (rather than "call") >> come >> from? Are you setting these yourself or running some optimization pass >> after >> your pass? >> >> >> i have written a module pass and i have compiled

Hi, The link "Broken versions of GCC and other tools" on http://llvm.org/docs/ReleaseNotes.html points to #brokengcc, where it should point to http://llvm.org/docs/GettingStarted.html#brokengcc I guess. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Joerg Sonnenberger <joerg at britannica.bec.de> writes: > The problem is answering the question of "do I have it or not". Linear > version numbers are much nicer for that. In the presence of branches, the version number alone doesn't answer this question, because the commit may be more recent than your HEAD, but in another branch. git branch --contains <sha1>, on

John McCall <rjmccall at apple.com> writes: >> git branch --contains <sha1>, on the other hand, will tell you. > > Of course, this doesn't actually help if you've cherry-picked commits > over to your branch (e.g. because it's a release branch). How is that different from SVN? If revision 1234 fixes a bug is some branch, and the last revision in your trunk

Thanks, I must have missed these, added. On Apr 22, 2010, at 1:28 AM, Matthieu Moy wrote: > Chris Lattner <clattner at apple.com> writes: > >> Ok, the LLVM 2.7 release notes are in near final shape. Please take >> a look and suggest improvements (or, better yet, just commit >> improvements if you have commit access): > > About the API changes, some that hit

Hi, I've had problem with a program using LLVM that tried to dynamic_cast objects created in the JIT execution engine, from the native part of the program (for the curious, the program is PinaVM http://gitorious.org/pinavm/pages/Home). I've narrowed down the issue to the linkage of weak_odr and linkonce_odr symbols, used for the vtables, and that _must_ be unique for dynamic_cast to

greened at obbligato.org (David A. Greene) writes: >> b) We need a document explaining how patches are reviewed and referred >> to, what commit rules (and hooks) are in place and how this would work >> in a git world. It would be short and sweet. > > I'm not exactly sure what you're asking for. My assumption is that the > hooks in place for git are the same

greened at obbligato.org (David A. Greene) writes: > Actually git pull can sometimes get you into trouble. Probably git > fetch / git rebase is the better combination for LLVM. I don't get it. Doesn't "git pull --rebase" do exactly a fetch followed by a rebase? -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Alexander MacDonald <alexmac at adobe.com> writes: > The topic of generation numbers has come up again recently on the git > lists and it looks like they might make it in > (http://stackoverflow.com/questions/6702821/ > git-commit-generation-numbers). Of course this isn't exactly the same > as svn because the numbers are only unique within a given branch, but > it

vmkit fails to build because llvm-as with llc -march=cpp generate wrong code for AttrListPtr AttrListPtr::get(ArrayRef< AttributeWithIndex >Attrs) http://llvm.org/doxygen/classllvm_1_1AttrListPtr.html#a3a19622d131e9f0d981398f54cf6acfc bellow you can see the faulty generated code llvm-as ./vmkit/lib/vmkit/Compiler/LLVMRuntime.ll -o - | llc -march=cpp -cppgen=contents -o - | grep

On Nov 13, 2012, at 12:20 AM, Bill Wendling wrote: > IR Changes > ---------- > > The attributes will be specified within the IR. This allows us to generate code > that the user wants. This also has the advantage that it will no longer be > necessary to specify all of the command line options when compiling the bit code > (via 'llc' or 'clang'). E.g.,

Chris Lattner <clattner at apple.com> writes: > Ok, the LLVM 2.7 release notes are in near final shape. Please take > a look and suggest improvements (or, better yet, just commit > improvements if you have commit access): About the API changes, some that hit me when I ported some code to LLVM 2.7, and not in the release notes (I had sent a private email some time ago) : ---

> On 24 Mar 2015, at 14:55, Aaron Ballman <aaron at aaronballman.com> wrote: > > On Tue, Mar 24, 2015 at 9:48 AM, Rinaldini Julien > <julien.rinaldini at heig-vd.ch> wrote: >> Hi, >> >> I want to *tag* some functions with some *flags*. I was using annotate((“myFlag”)) and everything was working fine until I tried on ObjC method. It seems that clang just