[cfe-dev] [RFC] automatic variable initialization

Wed Dec 5 18:06:46 PST 2018

I have the same question as David: I don't understand why this isn't just
an experimental build option disabled by default? (Google, Apple, etc. can
just enable it in their build script, no need to patch the source).

The only argument I read in the thread was about allowing people to make
performance measurement without rebuilding the compiler, but I have a hard
time reconciliation this with the fact that we're talking about not
shipping this before performing the actual measurements?

I expect that anyone that cares enough about the perf impact of this to
influence the development of the feature in clang should already be
rebuilding their compiler today.

-- 
Mehdi

On Mon, Dec 3, 2018 at 5:58 PM David Blaikie via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Just out of curiosity - what's the major difference between a build-time
> off-by-default feature and a build-time on-by-default-but-off-in-release
> branches feature? If we're only targeting groups that build/release the
> compiler themselves, then they're likely able to opt-in to a build-time
> feature easily enough, I'd think? & then there's no need to make our
> releases different from day-to-day builds?
>
> But sounds like folks are in general agreement of a way forward, so I
> don't want to disrupt/delay that.
>
> On Wed, Nov 28, 2018 at 11:14 PM Chandler Carruth <chandlerc at gmail.com>
> wrote:
>
>> Suggested compromise technique to at least get an initial set of numbers:
>>
>> 1) Require a special, long, ugly flag name.
>> 2) Make it a CC1 flag, requiring -Xclang ... to use.
>> 3) Emit a warning by default (that cannot be suppressed with a -Wno-...
>> flag) when this flag is enabled.
>> 4) Commit to never including this flag in any upstream release. Either we
>> remove it before the next release branches or we revert it on the branch.
>>
>> Most of the folks we're hoping to get performance data with are willing
>> to use a not-yet-released build of Clang. They won't have to actually patch
>> it in any way. They will have strong reminders to not deploy this in any
>> way due to the warning.
>>
>> Thoughts?
>>
>> On Wed, Nov 28, 2018 at 4:34 PM Kostya Serebryany via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> 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?
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>
>>
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181205/d8c51c5f/attachment.html>