search for: profiledata

...ransformUtils? >> > > Given that InlineCost is not really an analysis any longer, I think this is fine. Isn't it? It is not a pass, but I see it as an analysis utils. > >> >> I submitted r266477 (which has now been reverted) that made Analysis >> depend on ProfileData in order to obtain ProfileSummary for the >> module, but there is an existing dependency of ProfileData on >> Analysis (through Object and BitCode). The real issue is that BitCode depends on Analysis I think. I'm not sure about ProfileData that depends on Bitcode, do you know why?...

...tion -- it does not make sense to move > those code in to Analysis. For the same reason, we need to ask first if > InlineCost is intended to be a shared utility? > > > In the current case at stake: the issue is that we can't make the Analysis > library using anything from the ProfileData library. Conceptually there is > a problem IMO. > Yes -- this is a very good point. David > > Moving something from Analysis to TransformUtils just because it needs to > access ProfileData is a slippery slope... > > -- > Mehdi > > > > David > > > &...

...*"Xinliang David Li" <davidxl at google.com> > > On Mon, Apr 18, 2016 at 2:33 PM, Mehdi Amini <mehdi.amini at apple.com> > wrote: >> >> In the current case at stake: the issue is that we can't make the >> Analysis library using anything from the ProfileData library. Conceptually >> there is a problem IMO. >> > > > Yes -- this is a very good point. > > Independent of anything else, +1. > The design of ProfileData and reading profile information in the entire middle end had a really fundamental invariant that folks seem to...

...oogle.com> >>> >>> On Mon, Apr 18, 2016 at 2:33 PM, Mehdi Amini <mehdi.amini at apple.com> >>> wrote: >>>> >>>> In the current case at stake: the issue is that we can't make the >>>> Analysis library using anything from the ProfileData library. Conceptually >>>> there is a problem IMO. >>>> >>> >>> >>> Yes -- this is a very good point. >>> >>> Independent of anything else, +1. >>> >> >> The design of ProfileData and reading profile informati...

...i.amini at apple.com > <mailto:mehdi.amini at apple.com>> wrote: > > In the current case at stake: the issue is > that we can't make the Analysis library using > anything from the ProfileData library. > Conceptually there is a problem IMO. > > > > Yes -- this is a very good point. > > Independent of anything else, +1. > > > The design of ProfileData and reading profile information >...

...ofiling formats. Notably, (B) would make it a good place for a sample based profile reader, which currently lives in lib/Transforms with its usage. - If we go with (A), a name like Profile may be too generic, so something more specific like InstrProfile might be better. For (B), Profile or ProfileData seem best. The other part of the problem, (3), has no precedent that I'm aware of. Is there a way to include llvm libraries in compiler-rt that wouldn't cause problems? I don't plan on addressing this in the near future, but comments on what options are available would be appreciated.

...lly an analysis any longer, I think >> this is fine. >> >> Isn't it? It is not a pass, but I see it as an analysis utils. >> >> > >> >> >> >> I submitted r266477 (which has now been reverted) that made Analysis >> >> depend on ProfileData in order to obtain ProfileSummary for the >> >> module, but there is an existing dependency of ProfileData on >> >> Analysis (through Object and BitCode). >> >> The real issue is that BitCode depends on Analysis I think. >> I'm not sure about ProfileDat...

Hi, After r256521 - which removes InlineCostAnalysis class - I think there is no strong reason for InlineCost.cpp to be part of the Analysis library. Is it fine to make it part of TransformUtils? I submitted r266477 (which has now been reverted) that made Analysis depend on ProfileData in order to obtain ProfileSummary for the module, but there is an existing dependency of ProfileData on Analysis (through Object and BitCode). Moving InlineCost.cpp under Transforms/Utils will fix this issue. There are other ways to fix this (make Inliner.cpp get the ProfileSummary and pass it to I...

...ntly, the native profile reader for Linux Perf and the writer for LLVM's profile are part of the same tree. They both reside in llvm/tools/llvm-prof-converter. I would like to support more than Linux Perf, eventually. So, I'm thinking that I want to move the LLVM profile writer to llvm/lib/ProfileData and only have the various readers under llvm/tools/llvm-prof-converter. I don't think I will be working on supporting anything other than Linux Perf for now. But if anyone is interested in supporting profilers in other platforms, please let me know. I want to make sure the implementation doesn...

...lt; > > > > mehdi.amini at apple.com > > > > > wrote: > > > > > > > > > > > In the current case at stake: the issue is that we can't make > > > > > the > > > > > Analysis library using anything from the ProfileData library. > > > > > Conceptually there is a problem IMO. > > > > > > > > > > > > > > Yes -- this is a very good point. > > > > > > > > > Independent of anything else, +1. > > > > > The design...

...oogle.com> >>> >>> On Mon, Apr 18, 2016 at 2:33 PM, Mehdi Amini <mehdi.amini at apple.com> >>> wrote: >>>> >>>> In the current case at stake: the issue is that we can't make the >>>> Analysis library using anything from the ProfileData library. Conceptually >>>> there is a problem IMO. >>>> >>> >>> >>> Yes -- this is a very good point. >>> >>> Independent of anything else, +1. >>> >> >> The design of ProfileData and reading profile informati...

I’d like to nominate code owners for: PGO (CodeGenPGO, ProfileData, llvm.instprof): Justin Bogner Branch Weights and BlockFrequency: Duncan Smith -Andy

...ailure can be reproduced with: ./bin/llvm-config "--ldflags" "--libs" "--system-libs" all-targets analysis asmparser asmprinter bitreader bitwriter codegen core debuginfodwarf executionengine instrumentation interpreter ipo irreader linker mc mcjit objcarcopts option profiledata scalaropts support target Looking... -- Mehdi > On Feb 12, 2016, at 10:30 AM, Quentin Colombet <qcolombet at apple.com> wrote: > > Hi, > > This may happen because of r260569. > Now the libAArch64 has a dependency on libGlobalISel, though this one should also be gener...

...ome unit tests for some debug line error handling code I'm working on (see e.g. https://reviews.llvm.org/D44382), and I just ran into an annoying disabled feature in gtest, specifically the "Combine" feature for use in combinatorially generating parameterised tests. A FIXME comment in ProfileData\CoverageMappingTest.cpp suggests that I'm not the only one to have tried and discovered that they cannot use this feature. The problem is that the version of googletest (v 1.8.0, released in Aug 2016) in the LLVM tree requires TR1 tuple support for this feature, which is not really supported in...

...s: > Seems fine to me. Not sure if there is part of this that you want to > explicitly call out as owned by Diego. > > On Thu, Dec 11, 2014 at 12:38 AM, Andrew Trick <atrick at apple.com> wrote: > > I’d like to nominate code owners for: > > PGO (CodeGenPGO, ProfileData, llvm.instprof): Justin Bogner > > Branch Weights and BlockFrequency: Duncan Smith > > -Andy > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu > http://lis...

...| 1|#include <stdio.h> | 2| 0| 3|int foo() { return 42; } 1| 4|int main() { 1| 5| return 0; 1| 6|} As far I can understand issue somehow related to unused static functions. Also, as I can track down the problem raised because of lib/ProfileData/CoverageMappingReader.cpp (SectionData::get) expects that function's names located inside __llvm_prf_names section but it not true in case of test1.c, instead some function names located inside .rodata section. Is it known issue? any hints, how to avoid or workaround it? -- Be happy, Best r...

...ome debug line error handling > code I'm working on (see e.g. https://reviews.llvm.org/D44382), and I > just ran into an annoying disabled feature in gtest, specifically the > "Combine" feature for use in combinatorially generating parameterised > tests. A FIXME comment in ProfileData\CoverageMappingTest.cpp suggests that > I'm not the only one to have tried and discovered that they cannot use this > feature. The problem is that the version of googletest (v 1.8.0, released > in Aug 2016) in the LLVM tree requires TR1 tuple support for this feature, > which is not...

...rror handling >> code I'm working on (see e.g. https://reviews.llvm.org/D44382), and I just >> ran into an annoying disabled feature in gtest, specifically the "Combine" >> feature for use in combinatorially generating parameterised tests. A FIXME >> comment in ProfileData\CoverageMappingTest.cpp suggests that I'm not the >> only one to have tried and discovered that they cannot use this feature. The >> problem is that the version of googletest (v 1.8.0, released in Aug 2016) in >> the LLVM tree requires TR1 tuple support for this feature, which...

...> > > > > > > > > > > >> > > > > > > > > > > >> I submitted r266477 (which has now been reverted) that made > > > > >> Analysis > > > > > > > > > > >> depend on ProfileData in order to obtain ProfileSummary for > > > > >> the > > > > > > > > > > >> module, but there is an existing dependency of ProfileData > > > > >> on > > > > > > > > > > >> Analysis (thr...

...where, and the only error message I >> got was "Assertion `!Key.empty()' failed." from llvm-cov. > > I expect llvm-cov to print out "Failed to load coverage: <reason>" in > this situation. There was some work done to tighten up error reporting > in ProfileData and its clients in r270020. If your host toolchain does > have these changes, please file a bug, and I'll have it fixed. Host toolchain is trunk clang... but using system binutils (which is 2.24 on my Ubuntu 14.04 system... and apparently that's too old per David Li's response)....