[cfe-dev] [RFC] automatic variable initialization

Mon Dec 3 17:57:53 PST 2018

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181203/f70c3f29/attachment.html>