[cfe-dev] [RFC] automatic variable initialization

[Kostya Serebryany via cfe-dev]

>
>
>>> 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>
.
Besides that monolithic thing, we have Android, Chrome, ChromeOS, Fuchsia,
and a bazillion of smaller efforts that use their own toolchains.
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.




> 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/0c4eb400/attachment.html>