similar to: [LLVMdev] MergeFunctions: reduce complexity to O(log(N))

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

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

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, Please find the attached patch for review. -Stepan. John McCall wrote: > On Oct 28, 2011, at 2:00 AM, Stepan Dyatkovskiy wrote: >> I found next code when switch instruction differs: >> >> Engine.logf("right switch has extra case %r")<< CaseValue; >> >> Where CaseValue is a ConstantInt object. Looking how logf works I found >> that it

I just want to update test/Transforms/LowerSwitch/feature.ll that already uses grep. It uses grep + count, probably due to shorter construction. -Stepan. Eric Christopher wrote: > > On May 24, 2012, at 12:12 AM, Stepan Dyatkovskiy wrote: > >> Hi all. I found that if you want to use grep with escape characters in >> lit, you should pass it within the double slash (\\). Since

ping. -Stepan. Stepan Dyatkovskiy wrote: > Hi, > > Please find the attached patch for review. > > -Stepan. > > John McCall wrote: >> On Oct 28, 2011, at 2:00 AM, Stepan Dyatkovskiy wrote: >>> I found next code when switch instruction differs: >>> >>> Engine.logf("right switch has extra case %r")<< CaseValue; >>>

Hi all. The question about 'load' instruction. When we promote v2i5 = load <addr> ; <MemoryVT = v2i5> to v2i64 = load <addr> ;<MemoryVT = v2i5> should we insert vector shuffling that moves second v2i5 item to the second v2i64 item? Or it is still depends from target? Thanks. -Stepan.

Hi everybody. I found that there are some problems with symbol location in AsmParser. 1. We need to know where symbol was declared. 2. We need to know where symbol was defined first time. There are two ways: 1. Add helper table to the parser with additional symbol info. But it takes additional memory consumption. 2. Add user tag (void*) for MCSymbol object. As I understood MCSymbol can live

Yes. It doesn't works properly. I also read the your discussion in bug 1784: http://llvm.org/bugs/show_bug.cgi?id=1784 I found that know Type and Vector Lagalization and in DAGCombining implicitly assumed that element size of MemoryVT is multiply of 8 bits. Thats the main reason why v2i5 works improperly with load/store. But I can't determine exactly what MemoryVT means... -Stepan.

Hi Chris. There is no zero arrays created. Probably this patch is not optimal and I'll reworked it today. But the main idea is keep a single zero-item when ConstantAggregateZero was wrapped and return this zero item as result of getOperand call. Note that wrapper has no parent classes, it has very local and short lifetime (method body), it exists outside the LLVMContext and needed for