similar to: [LLVMdev] sharing code between tools

----- Original Message ----- > From: "Dehao Chen" <dehao at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Xinliang David Li" <davidxl at google.com>, "llvm-dev" > <llvm-dev at lists.llvm.org> > Sent: Tuesday, November 1, 2016 1:24:01 PM > Subject: Re: [llvm-dev] (RFC) Encoding code duplication factor in

On Fri, Dec 23, 2016 at 11:47 AM Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > A few disjoint thoughts; sorry they're so delayed (I skimmed the responses > below, and I think these are still relevant/not covered elsewhere). > > Firstly, why *should* DISubprogram definitions be distinct? There were > two reasons this was valuable (this was from before there

> On Dec 23, 2016, at 18:36, David Blaikie <dblaikie at gmail.com> wrote: > > > >> On Fri, Dec 23, 2016 at 11:47 AM Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> A few disjoint thoughts; sorry they're so delayed (I skimmed the responses below, and I think these are still relevant/not covered elsewhere). >> >> Firstly, why

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-851401618-1218751024=:15885 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE I didn't describe the problem clearly. It's about the number of distinct=20 values. So just

I'm looking at implementing a custom optimization level similar to the usual -0* family. I'd like to look at the implementations of the existing groups. Could anyone tell me where to find them? Thanks, --Paul

Hi Paul, That should be easy enough, because the LLVM build has no warnings in it! Some of us build with -Werror, and even with those of us that don't warnings are not tolerated. You're already seeing all the warnings that are coming out of the build :) Cheers, James ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf

Hi, I want to see any warning that are produced when I build llvm (in particular, those in code I'm writing). Before I do something quick and dirty with tee and grep, I was wondering if there was already something available to, for example, reprint warnings after a build completes? Thanks, --Paul

A few disjoint thoughts; sorry they're so delayed (I skimmed the responses below, and I think these are still relevant/not covered elsewhere). Firstly, why *should* DISubprogram definitions be distinct? There were two reasons this was valuable (this was from before there was a cu: link). - It helped to fix long-standing bugs in the IRLinker, where uniqued-DISubprograms in different compile

It looks like the example doesn't use the encoding described in the text? Assume that the discriminator is uint32. The traditional discriminator is less than 256, let's take 8 bit for it. For duplication factor (type 1 duplication), we assume the maximum unroll_factor * vectorize_factor is less than 256, thus 8 bit for it. For unique number(type 2 duplication), we assume code is at most

On Thu, Dec 15, 2016 at 11:26 AM Teresa Johnson <tejohnson at google.com> wrote: > Trying to wrap my brain around this, so a few questions below. =) > Sure thing - sorry, did assume a bit too much arcane context here. > > On Thu, Dec 15, 2016 at 10:54 AM, David Blaikie <dblaikie at gmail.com> > wrote: > > Branching off from a discussion of improvements to

----- Original Message ----- > From: "Dehao Chen" <dehao at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Xinliang David Li" <davidxl at google.com>, "llvm-dev" > <llvm-dev at lists.llvm.org> > Sent: Tuesday, November 1, 2016 11:43:41 AM > Subject: Re: [llvm-dev] (RFC) Encoding code duplication factor

On Thu, Dec 15, 2016 at 1:30 PM Teresa Johnson <tejohnson at google.com> wrote: On Thu, Dec 15, 2016 at 11:38 AM, David Blaikie <dblaikie at gmail.com> wrote: On Thu, Dec 15, 2016 at 11:26 AM Teresa Johnson <tejohnson at google.com> wrote: Trying to wrap my brain around this, so a few questions below. =) Sure thing - sorry, did assume a bit too much arcane context here.

On Thu, Dec 15, 2016 at 2:08 PM, David Blaikie <dblaikie at gmail.com> wrote: > On Thu, Dec 15, 2016 at 1:30 PM Teresa Johnson <tejohnson at google.com> > wrote: > > On Thu, Dec 15, 2016 at 11:38 AM, David Blaikie <dblaikie at gmail.com> > wrote: > > > > On Thu, Dec 15, 2016 at 11:26 AM Teresa Johnson <tejohnson at google.com> > wrote: >

On Thu, Dec 15, 2016 at 11:38 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Thu, Dec 15, 2016 at 11:26 AM Teresa Johnson <tejohnson at google.com> > wrote: > >> Trying to wrap my brain around this, so a few questions below. =) >> > > Sure thing - sorry, did assume a bit too much arcane context here. > > >> >> On Thu, Dec

On Thu, Dec 15, 2016 at 4:17 PM Teresa Johnson <tejohnson at google.com> wrote: > On Thu, Dec 15, 2016 at 2:08 PM, David Blaikie <dblaikie at gmail.com> wrote: > > On Thu, Dec 15, 2016 at 1:30 PM Teresa Johnson <tejohnson at google.com> > wrote: > > On Thu, Dec 15, 2016 at 11:38 AM, David Blaikie <dblaikie at gmail.com> > wrote: > > > > On

Do you have an estimate of the debug_line size increase? I guess it will be small. David On Thu, Oct 27, 2016 at 11:39 AM, Dehao Chen <dehao at google.com> wrote: > Motivation: > Many optimizations duplicate code. E.g. loop unroller duplicates the loop > body, GVN duplicates computation, etc. The duplicated code will share the > same debug info with the original code. For

Is there prior art for this sort of thing (in GCC, for example) - I take it this isn't the first time this has come up as a problem for profile accuracy? (so it'd be helpful to know prior solutions to this (& if we're not doing whatever was done before, what it is about our situation that's different, etc), or why it hasn't been a problem, etc) On Thu, Oct 27, 2016 at

On Thu, Dec 15, 2016 at 4:20 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Thu, Dec 15, 2016 at 4:17 PM Teresa Johnson <tejohnson at google.com> > wrote: > >> On Thu, Dec 15, 2016 at 2:08 PM, David Blaikie <dblaikie at gmail.com> >> wrote: >> >> On Thu, Dec 15, 2016 at 1:30 PM Teresa Johnson <tejohnson at google.com>

> On Dec 15, 2016, at 10:54 AM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Branching off from a discussion of improvements to DIGlobalVariable representations that Adrian's working on - got me thinking about related changes that have already been made to DISubprogram. > > To reduce duplicate debug info when things like linkonce_odr functions were

The large percentages are from those tiny benchmarks. If you look at omnetpp (0.52%), and xalanc (1.46%), the increase is small. To get a better average increase, you can sum up total debug_line size before and after and compute percentage accordingly. David On Thu, Oct 27, 2016 at 1:11 PM, Dehao Chen <dehao at google.com> wrote: > The impact to debug_line is actually not small. I only