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,