[cfe-dev] [RFC] automatic variable initialization

[Chandler Carruth via cfe-dev]

I'm super excited about all of the non-zeroing options here. I'd actually
like to mention some more options that I want to see explored (in future
work):

1) An enhancement to the pattern suggestion:

I'd like variables to be initialized to one of N patterns (using the very
nice pattern scheme you outline). The N patterns need to *include* zero.
The selection of the pattern needs to be very hard to rely on. My
suggestion would be to rotate between a shuffled list of patterns for each
initialization in the function (even better to do this in LLVM after
inlining etc). And shuffle the list of patterns using various inputs: the
version of the compiler, some user-provided input (random seed?), and the
(mangled) name of the function.

The reason I want this is that I think even all 0xAA can be relied upon
inadvertently by programmers. As an example: it will reliably initialize
booleans to `true`.

I would like to see something like this as the default instead of the
all-0xAA option.

2) An extension to this pattern (maybe call it "dynamic-pattern") would be
to read the pattern (or some of the N patterns) from a buffer initialized
at program start time.

While #2 may imply some overhead, it may be lower than expected -- copying
memory is in some weird cases faster than materializing patterns and then
setting memory. And it may have some advantages.


All of that said:

On Thu, Nov 15, 2018 at 5:06 PM Tim Northover via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Fri, 16 Nov 2018 at 00:42, JF Bastien <jfbastien at apple.com> wrote:
> > Sounds fair?
>
> No, it doesn't. It's putting the entire burden on backend optimizers,
> with the goal of removing zero-init at some unspecified future date.
> It's nothing even remotelty approaching a compromise.
>
> The fragmentation issues need to be considered up front.
>

FWIW, I agree about the zero case. I'm deeply concerned about fragmentation
here.

But I *also* really want to be able to get the data and measurements needed
to address performance problems with non-zero initialization.

I would love to see a way to get the zero initialization behavior for
performance testing, but *not* expose this as a supported flag to users. I
can imagine many ways to do that. Tim, would that address your concerns? In
that way, we could actually refuse to support the zero behavior long term
by making it much more apparent that it is only intended to gather data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181115/3a4ae1be/attachment.html>