similar to: [LLVMdev] Debug Info and MergeFunctions Transform

Hi David, After merging we always remove body of "G" (function we want to merge with "existing" one). In case with "writeThunk" we could add such info for "G", but it would be just a single string: reference to first string of "G". Ideal way here, is to merge debug information itself, and provide "F" with information for "G"

Hi all, I propose simple improvement for MergeFunctions pass, that reduced its complexity from O(N^2) to O(log(N)), where N is number of functions in module. The idea, is to replace the result of comparison from "bool" to "-1,0,1". In another words: define order relation on functions set. To be sure, that functions could be comparable that way, we have to prove that order

Hi Stepan, This looks interesting! Some high-level comments: - Please post the patch untarred next time. Also, I'm not sure if it's typical to provide supporting documents in .doc format; while many of us probably have access to Word, a more portable and email-friendly format (like text, markdown or rst) is probably better. - Have you profiled this? What's the speedup? I

Hi all, Previous patch has been split onto series of small changes. On each stage (after each patch) MergeFunctions pass is compilable and stable. Please find patches in attachment for review. To apply all patches at once, use "apply-patches.sh" script as follows: 0. Place "apply-patches.sh" in same directory with patches. 1. cd <llvm-sources-dir> 2. "bash

Hi all, Please find the updated patch in attachment: * Added some comments. * Fixed some typos. -Stepan Nick Lewycky wrote: > On 30 January 2014 01:27, Stepan Dyatkovskiy <stpworld at narod.ru > <mailto:stpworld at narod.ru>> wrote: > > Hello Sean and Tobias, > > Sean, > Thank you. Could you describe Nick's ideas in few words or give me >

Hi Tobias, > I can't really see a way to combine our approach with your patch. What > are your thoughts? I think it is possible. Even more - we need to combine our efforts, in order to bring this pass into real live. I'have read your presentation file, and unfortunately read your patch only a little. How exactly you scan functions on 2nd stage? Could you explain the algorithm in

Hi Nick, I tried to rework changes as you requested. One of patches (0004 with extra assertions) has been removed. > + bool isEquivalentType(Type *Ty1, Type *Ty2) const { > + return cmpType(Ty1, Ty2) == 0; > + } > > Why do we still need isEquivalentType? Can we nuke this? Yup. After applying all the patches isEquivalentType will be totally replaced with cmpType. All

On 2014 Jan 22, at 07:35, Stepan Dyatkovskiy <stpworld at narod.ru> wrote: > Hi Raul and Duncan, > > Duncan, > Thank you for review. I hope to present fixed patch tomorrow. > > First, I would like to show few performance results: > > command: "time opt -mergefunc <test>" > > File: tramp3d-v4.ll, 12963 functions > Current

Hi Nick. Can you help me sort some things out in MergeFucntions pass. While I was working on MergeFunctions pass I got several questions. I hardly tried to find all the answers by myself, but there are still two questions without answer. It is about merging functions itself (not comparing). First question is: Why sometimes we use RAUW and sometimes replaceDirectCallers. Would you help me

On 27 October 2013 11:30, Stepan Dyatkovskiy <stpworld at narod.ru> wrote: > Hi Nick. > > Can you help me sort some things out in MergeFucntions pass. While I was > working on MergeFunctions pass I got several questions. I hardly tried to > find all the answers by myself, but there are still two questions without > answer. > > It is about merging functions itself

Hi, I'm interested in finding ways to reduce code size. LLVM's MergeFunctions pass seems like a promising option, and I'm curious about its status in tree. Enabling MergeFunctions gives a 1% code size reduction across the entire iOS shared cache (a collection of a few hundred system-critical DSO's). The numbers are even more compelling for Swift code. In fact, the swift compiler

Hi Nikita, Glad to hear that Rust code can benefit a lot from this. I have put patches to enable merge-similar functions with thinLTO. https://reviews.llvm.org/D52896 etc. <https://reviews.llvm.org/D52896> This is more powerful than existing merge-functions pass and all we need to do is port these patches to trunk llvm. I'd be happy to help with this effort. -Aditya

Hi Nick, I have committed 0001 as r203788. I'm working on fixes for 0002 - 0014. > After reading through this patch series, I feel like I'm missing > something important. Where's the sort function? It looks like we're > still comparing all functions to all other functions. When you insert functions into std::set or its analogs it does all the job for you. Since

Hello, I'm Ruijie Fang, currently a 1st-year undergraduate at Princeton University, majoring in Computer Science. I am writing to to express my interest in the Google Summer of Code project: Improve MergeFunctions to incorporate MergeSimilarFunction patches and ThinLTO Support. I've read the LCTES'14 paper and found it quite interesting and comprehensible. I've also went as far

Hi all, We have 4 outstanding tests on clang-mergefunc-x86_64-freeBSD9.2 builder. I have introduced issues for them in bugzilla: http://llvm.org/bugs/show_bug.cgi?id=18089 http://llvm.org/bugs/show_bug.cgi?id=18056 Since we have opened issues for these tests, can we add them to ignore-list for this builder? It allows faster catch and fix other failures (if we get them). I also wandering, may be

Hello Sean and Tobias, Sean, Thank you. Could you describe Nick's ideas in few words or give me links to your discussion, so I could adapt my ideas to it. Tobias, Your patch fails on several modules in my benchmark (73 of ~1800 tests). I have sent one as attachment. See statistics files for more details, all the .ll files you could simply find in test-suite object directory (after

Hi Stepan, Sorry for the delay. It's great that you are working on MergeFunctions as well and I agree, we should definitely try to combine our efforts to improve MergeFunctions. Just to give you some context, the pass (with the similar function merging patch) is already being used in a production setting. From my point of view, it would be better if we focus on improving its capability

Hi Peter, After discovering several bugs in ArgumentPromotion and DeadArgumentElimination where llvm::Functions were replaced with similar functions (with the same name) to transform their type in some way, I started looking at all calls to llvm::Function::takeName to see if there were any other debug info quality bugs in similar callers. One such caller is the DataFlowSanitizer, and I don't

On Thu, Jun 4, 2015 at 3:58 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > Personally, I think the right approach is to add a bool to > createGlobalDCEPass defaulting to true named something like > IsAfterInlining. In most standard pass pipelines, GlobalDCE runs after > inlining for obvious reasons, so the default makes sense. The special case > is

On Tue, Oct 7, 2014 at 11:48 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Tue, Oct 07, 2014 at 10:04:30AM -0700, David Blaikie wrote: > > Hi Peter, > > > > After discovering several bugs in ArgumentPromotion and > > DeadArgumentElimination where llvm::Functions were replaced with similar > > functions (with the same name) to transform their type