[cfe-dev] [RFC] automatic variable initialization

[Arthur O'Dwyer via cfe-dev]

On Tue, Nov 27, 2018 at 5:56 PM Peter Collingbourne via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Tue, Nov 27, 2018 at 2:34 PM JF Bastien <jfbastien at apple.com> wrote:
>
>> On Nov 27, 2018, at 2:14 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
>> On Tue, Nov 27, 2018 at 1:50 PM JF Bastien via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> On Nov 27, 2018, at 10:16 AM, David Blaikie via cfe-dev <
>>> cfe-dev at lists.llvm.org> wrote:
>>> On Mon, Nov 26, 2018 at 6:55 PM Reid Kleckner <rnk at google.com> wrote:
>>>
>>>> On Mon, Nov 26, 2018 at 6:43 PM Kostya Serebryany via cfe-dev <
>>>> cfe-dev at lists.llvm.org> wrote:
>>>>
>>>>> On Sat, Nov 17, 2018 at 9:00 AM David Blaikie via cfe-dev <
>>>>> cfe-dev at lists.llvm.org> wrote:
>>>>>
>>>>>> Would it be that drastic to have this require a code change/compiler
>>>>>> rebuild to enable? It could be designed so the change is small/easy
>>>>>> (changing a constant) but that the default compilers we all ship around (&
>>>>>> especially not the official releases) don't allow access to this
>>>>>> functionality.
>>>>>>
>>>>>> Anyone wanting to gather data would have to make this small change,
>>>>>> rebuild their compiler, build their target with this feature & gatehr
>>>>>> results from there.
>>>>>>
>>>>>
>>>>> This will cripple our ability to do measurements because in many cases
>>>>> we can only build things with whatever is the production compiler.
>>>>> I'd rather just rename the flag to something like
>>>>> -ftrivial-auto-var-init=zero-SCARY-WARNING-ABOUT-VOID-WARRANTY-GOES-HERE
>>>>>
>>>> [...] Can we purposefully change the name of the zero-init flag /
>>> attribute on every release, until we finally remove it? Or is the only
>>> option to give up on 2. And add friction when trying to collect data?
>>>
>>
>> We can perhaps take inspiration from how the web platform introduces new
>> experimental features. Historically this was done using vendor prefixes,
>> but this didn't prevent people from using them (i.e. your 4). The approach
>> that Blink (and I believe other vendors) has taken is to put these features
>> behind a user configurable "enable experimental web platform features”
>> setting. [...]
>>
>> Experimental features for web stuff is often enabled through e.g.
>> about:flags or something similar (such as a command flag), you don’t
>> rebuild your browser. [...]
>>
>
> Yes it requires a rebuild but that's probably an order of magnitude more
> straightforward than requiring code changes. Although it's not exactly the
> same as web platform the basic idea is the same: enabling the feature is
> split up into two steps, where typically in "production" scenarios
> different entities are in control of the different steps. In the web
> platform case it's the web developer and the browser user and in our case
> it's the toolchain builder and the project maintainer.
>

That analogy doesn't make sense to me. In the web-platform case, if I want
to, let's say, disable Javascript, I don't rebuild my browser. I just click
the "Disable Javascript" button. (Of course, the browser author has no
particular reason to be scared that users might be running around with
Javascript disabled — it's none of his business. Personally, I think the
compiler dev *should* be equally not-scared at the prospect of users
running around with this undefined behavior disabled — it's none of his
business. But I admit that that *is* where the analogy to browsers breaks
down.)

I have worked for many (smallish) places, and none of them have ever built
their own Clang from source. That's just not something people do. They
compile *their own* C++ codebase, yes; but they leave the
compiling-of-the-compiler to the compiler devs. So any solution involving
"let's just make everyone build their own Clang from source" is going to be
a non-starter for the target audience (which, as I understand it, is people
with large buggy codebases who want to quickly benchmark the difference
between pattern-initialization and zero-initialization to convince
themselves that pattern-initialization is no more expensive than
zero-initialization, before going ahead and using pattern-initialization).

I guess if it's gated on an environment variable it's still possible for a
> project to enable the feature on its own by using "env" in its build
> commands.
>

How about a *combination* of scary environment variable and scary
command-line flag?
How about changing the spelling of the scary command-line flag on every
release?

I was going to suggest something like "make the spelling of the
command-line flag depend on the date and/or compiler binary itself, so you
have to `clang --what-is-todays-scary-spelling` and use that." But that
would break distributed builds.
I was going to suggest something like "error out unless the translation
unit contains a #pragma with a scary name opting in to the behavior." But
that would involve the user making code changes to their codebase, which is
a non-starter.

Personally, I think "scary command-line flag" is exactly the right level of
paranoia for this feature.
    "-Xclang -ftrivial-auto-var-init=FOR-INTERNAL-BENCHMARKING-ONLY"
Or smuggle it in under the guise of genericity:
    "-ftrivial-auto-var-init=pattern -Xclang
-ftrivial-auto-var-init-pattern=00000000".

my $.02,
–Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181127/649e828a/attachment.html>