[cfe-dev] FW: RFC: YAML as an intermediate format for clang::tooling::Replacement data on disk

[Manuel Klimek]

On Wed, Jul 31, 2013 at 10:42 PM, Chandler Carruth <chandlerc at google.com>wrote:

>
> On Wed, Jul 31, 2013 at 1:35 PM, Manuel Klimek <klimek at google.com> wrote:
>
>> I think the sequential part of that step should be in the core code, but
>> the parallelization will be in a (small) tool. This is also where
>> special-case logic for custom networked file systems or strange version
>> control systems would fall in.
>
>
> I really disagree. I don't know why we wouldn't aim to eventually have the
> core clang logic know all the necessary tricks to scalaing all aspects of
> this up. It shouldn't be sequestered like this.
>

> Consider, if you have the ability to do any amount of parallelism in the
> tool, you'd often like to pipeline the analysis and the updating of files,
> all while maintaining de-dup coherency etc. This would essentially require
> the same code to be managing both the running of the tool and the writing
> of the updates. In the case where you *don't* serialize the edits through
> some other layer, I think you still will want this, and thus it belongs in
> common shared library code.
>

While in an ideal world I would agree, I think the possible parallelization
frameworks we'll want to support are different enough that we always want
the parallelization framework to drive the analysis, and provide atoms that
can be put together effectively to achieve that.

I'm not saying that we shouldn't provide some common mechanism for
parallelizing in the core, I just think we need to architect it in a way
that the parallelization can be driven from outside, at which point the
parallelization in the core becomes less central to the whole design, and
thus I think less important to argue about.


> Naturally parallelism within a process of this kind (or any kind) of this
> kind is a long way off. I just don't want to not be thinking about it in
> terms of what the end goal looks like.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130731/5d49a949/attachment.html>