similar to: Status of the function merging pass?

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

Some time ago I saw a report of strange single-stepping behavior given Swift code that looks like this: 1| var input = [16, 14, 10, 9, 8, 7, 4, 3, 2, 1] //< Only number 1 is relevant. 2| print("start") TL;DR: The debugger steps from line 2 -> 1 -> 2 in this code example. One clean way to fix this bug is to remove debug locations from ConstantSDNodes, and I'm asking if

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 Stepan, 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 MergeFunctions, and I don't see

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, 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, 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 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 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

There have been a lot of responses. I'll try to summarize the thread and respond to some of the questions/feedback. Summary ======= 1. We should teach GlobalDCE to strip out instrumented functions which the inliner cannot delete. 2. Sean suggests adding metadata to loads/stores of counters to convey that they do not alias normal program data. I'm not familiar with AA, but

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

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'd like to add a new pass to LLVM which removes redundant profile counter updates. The goal is to speed up code coverage testing and profile generation for PGO. I'm sending this email out to describe my approach, share some early results, and gather feedback. Problem Overview ================ A profile counter is redundant if it's incremented in exactly the same basic blocks

Hi Sourabh, Thanks for raising this issue. To answer your question, (afaik) there isn’t anyone working on DW_AT_start_scope support in tree. We’re looking for a solution to this problem for Swift debugging, where it's important not to make a debug location for a variable available until its (guaranteed) initialization is complete. If at all possible, I’d /much/ rather we use the existing

> On Oct 1, 2018, at 3:25 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Mon, Oct 1, 2018 at 3:24 PM JF Bastien <jfbastien at apple.com <mailto:jfbastien at apple.com>> wrote: >> On Oct 1, 2018, at 3:16 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> (my vote, somewhat biased - is that

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

Hello everyone, I've been using LLVM for quite some time now (for writing my own toy compilers) and I've been following this mailing list for the last few months. I would like to start making contributions to the project. I have no particular area of interest right now (in the sense that I find pretty much all of LLVM fascinating). Are there any known low hanging fruit that I could tackle

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

Hello, I worked on a code size analysis tool for a 'week of code' project and think that it might be useful enough to upstream. The tool is inspired by bloaty (https://github.com/google/bloaty), but tries to do more to attribute code size in actionable ways. For example, it can calculate how many bytes inlined instances of a function added to a binary. In its diff mode, it can show how