[cfe-dev] making -ftrivial-auto-var-init=zero a first-class option
JF Bastien via cfe-dev
cfe-dev at lists.llvm.org
Wed Apr 22 09:26:46 PDT 2020
> 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:
>> 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
>> or rename it to something more directly reflecting the issue, like
>> 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
>> 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"):
>> 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
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...
More information about the cfe-dev