[cfe-dev] [RFC] automatic variable initialization

[Kostya Serebryany via cfe-dev]

On Wed, Nov 28, 2018 at 3:28 PM David Blaikie <dblaikie at gmail.com> wrote:

>
>
> On Wed, Nov 28, 2018 at 3:17 PM Kostya Serebryany <kcc at google.com> wrote:
>
>>
>>>>> Seems easier to me to separate the two pieces - move ahead with the
>>>>> non-zero options, and separate the discussion on the zero option. You can
>>>>> present performance numbers from what you can measure without shipping a
>>>>> compiler with the feature - and if those numbers are sufficiently
>>>>> compelling compared to the risks of slicing the language, then perhaps we
>>>>> go that way.
>>>>>
>>>>
>>>> This approach will significantly impair my ability to do the
>>>> measurements I need.
>>>>
>>>
>>> I'm aware waht I'm proposing would make it more difficult for some
>>> people to take measurements - that's a tradeoff to be sure - one where I
>>> err in this direction.
>>>
>>> Specifically for Google though - would it be that difficult for Google
>>> to opt-in to a certain build configuration of LLVM?
>>>
>>
>> Absolutely yes.
>> Google is not just a single monolithic code base
>> <http://delivery.acm.org/10.1145/2860000/2854146/p78-potvin.pdf?ip=104.133.8.94&id=2854146&acc=OA&key=4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E5945DC2EABF3343C&__acm__=1543446999_3aadcd36f657e2297430c38bee93f16c>
>> .
>>
>
> Couldn't access this link ("An error occurred while processing your
> request" - but yeah, I understand there's a bunch of different pieces of
> Google beyond the "stuff that runs in data centers" piece we mostly support.
>
>
>> Besides that monolithic thing, we have Android, Chrome, ChromeOS,
>> Fuchsia, and a bazillion of smaller efforts that use their own toolchains.
>>
>
> Still, most/all of these build their own compilers, I think? But yeah,
> that adds an opt-in overhead to each project, for sure.
>
>
>> In some cases the most reliable and complete way of measuring performance
>> changes is to submit the changes to revision control,
>> and let the performance bots shew it for a couple of days. That's how we
>> iterated with the LLVM's CFI in Chrome.
>> We will also need to work with the upstream Linux kernel -- it's hard
>> enough for them to use clang and a modified clang will cost us much more
>> effort.
>>
>
> Yeah, I can imagine that one's a bit trickier - how's performance
> evaluation of the kernel done?
>

I don't think anyone knows that. :-|
And requiring a compiler patch will shift the problem from "hard" to "I'd
better do something else".


> (though, again, I imagine a fair amount of progress could be made without
> the zero-init feature - perhaps enough to say "hey, here are all the places
> we have run tests & seen the performance tradeoff is worthwhile for us (&
> possibly that it's close to the zero-init case, but that's sort of
> orthogonal, imho - that it's worthwhile is the main thing) - perhaps other
> folks would be willing to test it (non-zero init) & see if it's worthwhile
> to them - and if it isn't/they're interested in more performance, maybe all
> that evidence we can gain from the places where it's easy for us to rebuild
> compilers, etc, would make it interesting enough to motivate someone to do
> build the kernel with a custom compiler & do some performance measurements,
> etc...
>
> Sorry that was a bit rambly, anyway.
>
> - Dave
>
>
>>
>>
>>
>>
>>> We/Google do build the compiler from scratch, I assume we pick the
>>> configuration options we build with & some of them probably aren't the
>>> defaults for a release build of LLVM. So if it was important that Google's
>>> production compiler had these features enabled (rather than building a test
>>> compiler for running some experiments), that doesn't seem (at least to me,
>>> at this moment) especially prohibitive, is it?
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181128/7e26465e/attachment.html>