[cfe-dev] [RFC] automatic variable initialization

Thu Dec 6 15:55:29 PST 2018

On Thu, Dec 6, 2018 at 3:43 PM Kostya Serebryany <kcc at google.com> wrote:

>
>
> On Thu, Dec 6, 2018 at 3:03 PM Mehdi AMINI <joker.eph at gmail.com> wrote:
>
>>
>>
>> On Thu, Dec 6, 2018 at 1:01 PM Kostya Serebryany <kcc at google.com> wrote:
>>
>>>
>>>
>>> On Wed, Dec 5, 2018 at 6:07 PM Mehdi AMINI via cfe-dev <
>>> cfe-dev at lists.llvm.org> wrote:
>>>
>>>> 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).
>>>>
>>>
>>> I will need to rebuild half a dozen compiler binaries to do the
>>> measurements I need.
>>> This is going to double the cost of the effort for me because it adds
>>> too many extra moving pieces.
>>>
>>
>> Not sure I follow, you have to build the compiler anyway to get it after
>> the code is patched?
>> The only thing you would have to do is one CL to enable the build flag
>> (that expose the command line flag) inside your codebase and then you get
>> your toolchain as usual?
>>
>
> Once the JF's patch is in, I'll have it in most production compilers I
> care about in 2-6 weeks, w/o any effort on my side.
> None of those builders (easily) support adding custom patches, and even a
> build flag is going to be very non-trivial.
> I can deal with one or two of those builds relatively easily, but not with
> the rest.
>

What builders are you referring to? So far I was assuming we were talking
about your internal infrastructure that produces your production compilers.

>
>
>
>>
>> --
>> Mehdi
>>
>>
>>
>>
>>>
>>>
>>>>
>>>> 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
>>>>>
>>>> _______________________________________________
>>>> 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/20181206/70f1b90d/attachment.html>