[llvm-dev] [XRay][RFC] Tooling for XRay Trace Analysis

[Dean Michael Berris via llvm-dev]

> On 26 Aug 2016, at 03:26, Chris Bieneman <cbieneman at apple.com> wrote:
> 
> I totally did not mean to make the response off list.
> 

Thanks Chris, I'm adding the list to this response. Those interested should see the short discussion quoted below.

Adding Chandler explicitly for points raised by Chris below. Thoughts?

Cheers

-- Dean

> 
>> On Aug 24, 2016, at 5:58 PM, Dean Michael Berris <dean.berris at gmail.com> wrote:
>> 
>> 
>>> On 25 Aug 2016, at 04:27, Chris Bieneman <cbieneman at apple.com> wrote:
>>> 
>>> 
>>> 
>>> On Aug 23, 2016, at 1:05 AM, Dean Michael Berris via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>> 
>>>> 
>>>> # Open Questions
>>>> 
>>>> - Is it possible to define the writer code in LLVM and have the compiler-rt implementation depend on it? I hear that this is going to be useful for something like the profiling library in compiler-rt too, so that the readers and writer implementations are both in LLVM. What are the technical roadblocks there, and in your opinion is this something worth fixing/enabling?
>>> 
>>> There are two problems with this.
>>> 
>>> (1) Compiler-RT is under a slightly different license from LLVM. This complicates sharing code, or even moving code between the two projects. Specifically, Compiler-RT's license does not require attribution for code embedded in binaries, LLVM's does.
>>> 
>>> (2) Compiler-RT is commonly used without LLVM, and vice-versa. Adding a dependency from Compiler-RT to LLVM breaks this, and fundamentally alters the ways in which Compiler-RT can be used. While it would be possible to say Xray requires LLVM, while the rest of Compiler-RT doesn't, I think this would make a better argument for breaking Xray out of Compiler-RT rather than changing Compiler-RT's dependency promise.
>>> 
>> 
>> Thanks Chris! I wasn't aware of the licensing difference. That does complicate it a bit.
>> 
>> We've thought about breaking XRay out into a separate project, but haven't gotten there yet because it's just much more convenient to host it in already existing projects. Maybe it's time to think about this a bit more seriously then.
>> 
>> Cheers
>> 
>> PS. I kept the reply just to you, not sure if you intended to reply just to me or including the list.
>> 
>> -- Dean
>> 
>