similar to: LLD status update and performance chart

Displaying 20 results from an estimated 4000 matches similar to: "LLD status update and performance chart"

2016 Dec 16
0
LLD status update and performance chart
I talked several people and found that this is more like a communication issue rather than a technical/philosophical issue. I believe communication problems won't solve themselves. As a person who is on the owners file of LLD, I think I need to say something about that issue. Also, I guess people who were just watching this thread wondered why my happy pre-holiday status report suddenly turned
2016 Dec 16
2
LLD status update and performance chart
Hi Rui I agree separating the components out in to libraries only makes sense when there is a clear reason to do so. However, just this year there was a very involved discussion about what it means to be a library. Specifically, I don't think your current 'main-as-library' argument is valid while you call exit or (if you) rely on mutable global state. Having a single entry point
2016 Dec 16
0
LLD status update and performance chart
On Fri, Dec 16, 2016 at 11:18 AM, Pete Cooper <peter_cooper at apple.com> wrote: > Hi Rui > > I agree separating the components out in to libraries only makes sense > when there is a clear reason to do so. However, just this year there was a > very involved discussion about what it means to be a library. > Specifically, I don't think your current
2016 Dec 16
4
LLD status update and performance chart
> On Dec 16, 2016, at 11:46 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Fri, Dec 16, 2016 at 11:18 AM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote: > Hi Rui > > I agree separating the components out in to libraries only makes sense when there is a clear reason to do so. However, just this year there was a very
2016 Dec 18
2
LLD status update and performance chart
> On Dec 17, 2016, at 6:32 PM, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Fri, Dec 16, 2016 at 12:31 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >> On Dec 16, 2016, at 11:46 AM, Rui Ueyama <ruiu at google.com <mailto:ruiu at google.com>> wrote: >>
2016 Dec 18
0
LLD status update and performance chart
On Sat, Dec 17, 2016 at 6:45 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Dec 17, 2016, at 6:32 PM, Sean Silva via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On Fri, Dec 16, 2016 at 12:31 PM, Pete Cooper via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> On Dec 16, 2016, at 11:46 AM, Rui Ueyama <ruiu at
2016 Dec 18
1
LLD status update and performance chart
> On Dec 17, 2016, at 6:54 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Sat, Dec 17, 2016 at 6:45 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Dec 17, 2016, at 6:32 PM, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>
2016 Dec 18
0
LLD status update and performance chart
On Fri, Dec 16, 2016 at 12:31 PM, Pete Cooper via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On Dec 16, 2016, at 11:46 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Fri, Dec 16, 2016 at 11:18 AM, Pete Cooper <peter_cooper at apple.com> > wrote: > >> Hi Rui >> >> I agree separating the components out in to libraries only makes sense
2016 Dec 14
0
LLD status update and performance chart
On Mon, Dec 12, 2016 at 8:13 AM, Rafael Avila de Espindola via llvm-dev < llvm-dev at lists.llvm.org> wrote: > David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > On 12 Dec 2016, at 03:39, Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> > >> LLD's driver currently takes only a command line argument
2016 Dec 12
0
LLD status update and performance chart
On 12 December 2016 at 16:16, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > BTW, can you link it if you enable only the ARM target? Last time I > tried on TK1 the only remaining issue was the range extension thunks and > with only one target we got lucky and didn't need them. That's a good point! Peter, have you tried that? Indeed, thunks were the main
2017 May 03
4
DWARF Fission + ThinLTO
So Dehao and I have been dealing with some of the nitty gritty details of debug info with ThinLTO, specifically with Fission(Split DWARF). This applies to LTO as well, so I won't single out ThinLTO here. 1) Multiple CUs in a .dwo file Clang/LLVM produces a CU for each original source file - these CUs are kept through IR linking (thin or full) and produced as distinct CUs in the resulting
2013 Dec 09
2
[LLVMdev] DebugInfo: DW_AT_GNU_ranges_base in non-fission
It looks like we only attach the GNU_ranges_base to skeleton CUs, and never use the attribute under non-fission. Is that right? It's not obvious to me why we'd want to only include this under fission, but I admittedly don't fully understand it anyway. - Dave
2013 Dec 09
0
[LLVMdev] DebugInfo: DW_AT_GNU_ranges_base in non-fission
On Mon, Dec 9, 2013 at 9:47 AM, David Blaikie <dblaikie at gmail.com> wrote: > It looks like we only attach the GNU_ranges_base to skeleton CUs, and > never use the attribute under non-fission. Is that right? It's not > obvious to me why we'd want to only include this under fission, but I > admittedly don't fully understand it anyway. > So we're not
2017 Dec 16
3
[RFC] - Deduplication of debug information in linkers (LLD).
?But could not we for example do split dwarf, but for example do dedup of types ? I do not mean right now, but in a theory ? Best regards, George | Developer | Access Softek, Inc ________________________________ От: David Blaikie <dblaikie at gmail.com> Отправлено: 16 декабря 2017 г. 22:25 Кому: George Rimar Копия: Sean Silva; llvm-dev at lists.llvm.org; Rui Ueyama; Rafael Espindola Тема:
2013 Dec 09
1
[LLVMdev] DebugInfo: DW_AT_GNU_ranges_base in non-fission
On Mon, Dec 9, 2013 at 11:48 AM, Eric Christopher <echristo at gmail.com> wrote: > On Mon, Dec 9, 2013 at 9:47 AM, David Blaikie <dblaikie at gmail.com> wrote: >> It looks like we only attach the GNU_ranges_base to skeleton CUs, and >> never use the attribute under non-fission. Is that right? It's not >> obvious to me why we'd want to only include this
2017 May 03
3
DWARF Fission + ThinLTO
On Wed, May 3, 2017 at 2:09 PM Adrian Prantl <aprantl at apple.com> wrote: > > > On May 3, 2017, at 2:00 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > So Dehao and I have been dealing with some of the nitty gritty details > of debug info with ThinLTO, specifically with Fission(Split DWARF). > > > > This applies to LTO as well, so I
2017 May 04
2
DWARF Fission + ThinLTO
> On May 3, 2017, at 7:43 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On May 3, 2017, at 2:59 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> >> >> On Wed, May 3, 2017 at 2:09 PM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
2017 May 04
2
DWARF Fission + ThinLTO
On Thu, May 4, 2017 at 7:22 AM, Rafael Avila de Espindola via llvm-dev < llvm-dev at lists.llvm.org> wrote: > David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > So Dehao and I have been dealing with some of the nitty gritty details of > > debug info with ThinLTO, specifically with Fission(Split DWARF). > > > > This applies to LTO as
2016 Dec 12
2
LLD status update and performance chart
Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> writes: > ARM support is coming a long way, but we're still not able to link Clang > yet, and there are some issues on the test-suite. We'll be continuing to > make progress throughout next year and hopefully have a similar buildbot on > ARM. BTW, can you link it if you enable only the ARM target? Last time I tried
2017 May 05
2
DWARF Fission + ThinLTO
> On May 4, 2017, at 4:53 PM, David Blaikie <dblaikie at gmail.com> wrote: > > Alrighty, a little fuzzy on how best to implement this - Adrian, you've probably got the most context here as to how to wrangle this. > > My first attempt was in IRMover.cpp, IRLinker::linkFunctionBody - after metadata is copied over, create a new subprogram derived from Dst.getSubprogram,