similar to: Finding line numbers in source code associated with given bitcode instructions

I'm not sure if this was intended, but it's going to be a problem for sample profiles. When we compile with -gmlt, the profiler expects to find the line number for all the function headers so that it can compute relative line locations for the profile. The tool that reads the ELF binary is not finding them, so it writes out absolute line numbers, which are impossible to match during the

On Sun, Oct 26, 2014 at 7:23 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > The fundamental questions we need to answer are the following: > FWIW, there was a longer discussion on the lists when the actual option was added. I'll try to relay my memory of that discussion, but you might need to track it down or involve some of the other people who participated in it.

For -Rpass, and other related uses, I am looking at enabling column info by default. David pointed me at PR 14106, which seems to be the original motivation for introducing -gcolumn-info. However, I am finding no differences when using it on this test. I've tried building with/without -gcolumn-info and found almost no difference in compile time (+0.4%): $ /usr/bin/time clang -w -fno-builtin

On Fri, Oct 24, 2014 at 4:06 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > Diego, > > I think sampleFDO needs to be designed in a way which can protect itself > from future breakage like this. The roots in the unnecessary dependency of > sample FDO on gmlt setting. It is totally reasonable to tune debug binary > size by changes like this. > > The right way

On Fri Oct 24 2014 at 6:21:14 PM David Blaikie <dblaikie at gmail.com> wrote: > On Fri, Oct 24, 2014 at 3:16 PM, Diego Novillo <dnovillo at google.com> > wrote: > >> >> >> On Fri Oct 24 2014 at 6:11:21 PM David Blaikie <dblaikie at gmail.com> >> wrote: >> >>> On Fri, Oct 24, 2014 at 2:48 PM, Diego Novillo <dnovillo at

On Oct 30, 2013 7:25 PM, "Philip Reames" <listmail at philipreames.com> wrote: > > On 10/30/13 7:09 PM, Philip Reames wrote: >> >> David, Quentin - Thanks for the feedback. Responses inline. >> >> On 10/30/13 11:21 AM, David Blaikie wrote: >>> >>> Actually CCing Eric. >>> >>> >>> On Wed, Oct 30, 2013 at

On 10/30/13 7:09 PM, Philip Reames wrote: > David, Quentin - Thanks for the feedback. Responses inline. > > On 10/30/13 11:21 AM, David Blaikie wrote: >> Actually CCing Eric. >> >> >> On Wed, Oct 30, 2013 at 11:00 AM, Quentin Colombet >> <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >> >> Philip, >>

On Wed, Oct 30, 2013 at 8:58 PM, Eric Christopher <echristo at gmail.com>wrote: > > On Oct 30, 2013 7:25 PM, "Philip Reames" <listmail at philipreames.com> > wrote: > > > > On 10/30/13 7:09 PM, Philip Reames wrote: > >> > >> David, Quentin - Thanks for the feedback. Responses inline. > >> > >> On 10/30/13 11:21 AM,

On Fri Oct 24 2014 at 6:11:21 PM David Blaikie <dblaikie at gmail.com> wrote: > On Fri, Oct 24, 2014 at 2:48 PM, Diego Novillo <dnovillo at google.com> > wrote: > >> I'm not sure if this was intended, but it's going to be a problem for >> sample profiles. >> >> When we compile with -gmlt, the profiler expects to find the line number >>

Hi! Currently Clang "-g" flag emits full debug info, which is fine for debugging, but increases the binary size significantly. It may be useful to produce less debug info, that is still enough for collecting nice stack traces with file names and line numbers, but would introduce less overhead. Cary Coutant made a patch which does this for GCC (it didn't hit trunk yet) - reduces

On Thu, Aug 28, 2014 at 11:51 AM, Alexey Samsonov <vonosmas at gmail.com> wrote: > This sounds great. Teaching backend about the -gmlt might help us in > another way: we might enforce full debug info generation in the frontend > for -fsanitize= flags, then rely on some parts of this debug info in > instrumentation passes and prune it before the actual object file >

On Sun, Oct 26, 2014 at 4:59 PM, Eric Christopher <echristo at gmail.com> wrote: > On Fri, Oct 24, 2014 at 3:27 PM, Diego Novillo <dnovillo at google.com> > wrote: > > > > > > On Fri Oct 24 2014 at 6:21:14 PM David Blaikie <dblaikie at gmail.com> > wrote: > >> > >> On Fri, Oct 24, 2014 at 3:16 PM, Diego Novillo <dnovillo at

In an effort to fix inlined information for backtraces under DWARF Fission in the absence of the split DWARF (.dwo) files, I'm planning on adding -gmlt-like data to the .o file, alongside the skeleton CU. Since that will involve teaching the LLVM about -gmlt (moreso than it already has - the debug info LLVM metadata already describes -gmlt for the purposes of omitting pubnames in that case) I

On Sun, Oct 26, 2014 at 3:47 PM, Jeremy Lakeman <Jeremy.Lakeman at gmail.com> wrote: > This sounds like a problem best solved by tracking source code movement via > your source control system. > If you know the commit of the code that produced the sample, you should be > able to use source control history / diffs to translate absolute line > numbers to the location where the

On Apr 5, 2012, at 10:24 AM, Alexey Samsonov <samsonov at google.com> wrote: > Hi! > > Currently Clang "-g" flag emits full debug info, which is fine for debugging, but increases the binary size significantly. > It may be useful to produce less debug info, that is still enough for collecting nice stack traces with file names and line numbers, > but would introduce

Actually CCing Eric. On Wed, Oct 30, 2013 at 11:00 AM, Quentin Colombet <qcolombet at apple.com>wrote: > Philip, > > Thanks for the clarification. > > As far as I can tell, there is currently no way to preserve a full and > accurate stack trace while utilizing most of LLVM’s optimization abilities. > > The work on debug information may help you get the information

% clang -S -O3 -mcpu=cortex-a57 -ffast-math -Rpass-analysis=loop-vectorize dot.c dot.c:15:1: remark: loop not vectorized: value that could not be identified as reduction is used outside the loop [-Rpass-analysis=loop-vectorize] } ^ dot.c:15:1: note: could not determine the original source location for :0:0 I found “llvm-as < /dev/null | llc -march=aarch64 -mattr=help” which listed a

Hi, I am trying to compare the loop vectorizers effectiveness for different targets relative to each other. That way, I am hoping to find loops that are not vectorized - but could be - on my target by finding other targets doing this successfully. With some luck, there might be something in the Target files that could be fixed with improved vectorization as a result... I would like to do

David, Quentin - Thanks for the feedback. Responses inline. On 10/30/13 11:21 AM, David Blaikie wrote: > Actually CCing Eric. > > > On Wed, Oct 30, 2013 at 11:00 AM, Quentin Colombet > <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: > > Philip, > > Thanks for the clarification. > > As far as I can tell, there is currently

Hi -- I have found a bug in an HPC code where llvm is vectorizing a loop on Skylake that has an obvious recurrence. I derived a small test case based on the original benchmark below: /*****************************************************************/ static void __attribute__ ((always_inline)) one( const int *restrict in, const int *const end, const unsigned shift, int *const restrict index,