[cfe-dev] making -ftrivial-auto-var-init=zero a first-class option

[JF Bastien via cfe-dev]

> On Apr 22, 2020, at 2:30 AM, Alexander Potapenko <glider at google.com> wrote:
> 
> On Wed, Apr 22, 2020 at 5:43 AM JF Bastien <jfbastien at apple.com <mailto:jfbastien at apple.com>> wrote:
>> 
>> 
>> 
>> On Apr 21, 2020, at 2:20 PM, Kees Cook <keescook at chromium.org> wrote:
>> 
>> Hi,
>> 
>> tl;dr: I'd like to revisit making -ftrivial-auto-var-init=zero an expressly
>> supported option. To do this, I think we need to either entirely remove
>> "-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang"
>> or rename it to something more directly reflecting the issue, like
>> "-enable-trivial-auto-var-init-zero-knowing-it-forks-the-language".
>> 
>> This is currently open as https://bugs.llvm.org/show_bug.cgi?id=45497
>> 
>> Here is the situation: -ftrivial-auto-var-init=pattern is great for
>> debugging, but -ftrivial-auto-var-init=zero is needed for production
>> systems for mainly two reasons, each of which I will try to express context
>> for:
>> 
>> 1) performance and size
>> 
>> As measured by various Google folks across a few projects and in
>> various places, there's a fairly significant performance impact of
>> using pattern-init over zero-init. I can let other folks chime in
>> with their exact numbers, but I can at least share some measurements
>> Alexander Potapenko made with the Linux kernel (see "Performance costs"):
>> https://clangbuiltlinux.github.io/CBL-meetup-2020-slides/glider/Fighting_uninitialized_memory_%40_CBL_Meetup_2020.pdf
>> tl;dr: zero-init tended to be half the cost of pattern-init, though it
>> varied based on workload, and binary size impact fell over 95% going
>> from pattern-init to zero-init.
>> 
>> 
>> The main reason folks were OK with me putting in zero init *at all* was to compare performance between 1) no init 2) zero init 3) pattern init, and *then* tune pattern init to the “floor” set by zero init. In other words: try to get to as low a cost as possible. I and other optimizer folks put significant efforts towards this, and we still are, but we’ve only done so for our binaries, and only on front-end / middle-end / ARM64. There’s still very low-lying fruit for pattern init on x86, and there’s more to be optimized on ARM64 and general middle-end. I’m therefore not sure we’re honoring the spirit of the agreement without putting in more optimization effort. To clarify: the performance got better, but we haven’t tried enough to declare “pattern init will definitely never get acceptably close to zero init”.
>> 
>> At the same time, it’s pretty obvious that synthesizing zero will always be cheaper than synthesizing repeated bytes. The question we’ve still to answer is: does this matter?
> 
> 
> It is true that pattern initialization has recently become a lot
> faster. Thanks for all the efforts!
> 
> But one of the reasons to switch from pattern initialization to zero
> initialization is that the former breaks buggy code that happened to
> work previously.
> I.e. along with making production code more secure (by mitigating
> information leaks) we also introduce new crashes, making it less
> stable.

All I’m saying is what the original bar for acceptance was for zero-init: it was added with performance comparison as the justification, and I think folks expect us to deliver in that area (compare performance, and tune until they’re as close as can reasonably be).

What you mention here is new data which I think folks would want to consider. It's a valuable point to make, it would be useful to have data backing it up. However, I don’t think it invalidates the original performance comparison discussion, but it might make it less important.


>> I’d like to see the remainder of the optimization work happen. It benefits generic code, not just pattern init. I don’t think it’s a mountain of work.
> 
> 
> 
> -- 
> Alexander Potapenko
> Software Engineer
> 
> Google Germany GmbH
> Erika-Mann-Straße, 33
> 80636 München
> 
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200422/fac2cc10/attachment-0001.html>