[LLVMdev] RFC: Binary format for instrumentation based profiling data

[Chandler Carruth]

On Fri, Apr 18, 2014 at 12:58 PM, "C. Bergström"
<cbergstrom at pathscale.com>wrote:

> On 04/19/14 02:47 AM, Chandler Carruth wrote:
>
>
>> On Fri, Apr 18, 2014 at 12:22 PM, Evan Cheng <evan.cheng at apple.com<mailto:
>> evan.cheng at apple.com>> wrote:
>>
>>     I agree the top priority should always be "getting it right”. But
>>     I can’t agree with this thinking completely. This has to be
>>     balanced with pragmatism. If we completely disregard the practical
>>     concerns of commercial use, it makes LLVM hostile towards an
>>     important group of users.
>>
>>
>> Clearly, I can't argue with that. =] We benefit from it as well. And I
>> don't think I'm arguing against a pragmatic approach in this case, although
>> I'm sorry if it comes off that way.
>>
>> Just so we're on the same page, the only real question in my mind is: can
>> we make breaking changes as we iterate on the design.
>>
>> What I would like to do is figure out the right design first,
>> incrementally, trying one format, and seeing how it does, but potentially
>> with backwards incompatible changes. Once we have the experience and know
>> what the right format is, *then* we should consider pragmatic concerns such
>> as how to structure support for reading legacy formats, or formats outside
>> of the control of the project. I think if we start off with a format that
>> we can't change because of external reasons (whatever they may be), it will
>> be much harder to incrementally get to the right design. Does that seem
>> reasonable (and hopefully help explain the concrete suggestion I'm making)?
>>
> Why can't we have our cake and eat it too?
>
> Off the cuff and flame away
> ------------
> What's wrong with a soft policy like - Feel free to do an incremental
> improvement which breaks a change and then if someone else wants to
> contribute a patch that allows the old format/behavior - that's up to them
> (patches welcome). Both changes would be accepted and allows the parallel
> paths - (putting the burden of maintenance for backward compatibility on
> those stakeholders). Wouldn't this solve the problem Right Now(tm)?
>

I think its important that there remain incentives for the contributors to
address design feedback that comes up in review essentially. Making it
"patches welcome" right away, removes that incentive IMO, and would be a
shame. Sometimes, its unavoidable, but I think the project is better when
we hold that line.

As an example, when we wanted to contribute the AST matchers to Clang, is
was really useful that it was entirely on us to address all of the
(excellent) design review from Doug. It may not have mattered for our use
cases, but it mattered that the not-quite-right solution didn't just sit
rotting in mainline waiting for someone to take up the challenge of making
it the right solution.

The pragmatic tradeoff here is to do it incrementally, so you don't have to
leap to the right solution before the first patch lands. And I don't think
there has been any pushback against that in this thread.


> I don't mean this as an attack
> It's very depressing to see passionate Apple vs Google people not be able
> to come to middle ground very quickly
>

=] I think we're actually pretty close, and the discussion continues to be
polite, and non-circular, so I'm not depressed yet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140418/4fc93b13/attachment.html>