From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C00C2C10F03 for ; Tue, 23 Apr 2019 19:42:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9010821738 for ; Tue, 23 Apr 2019 19:42:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="YUaS/fUe" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726830AbfDWTmt (ORCPT ); Tue, 23 Apr 2019 15:42:49 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:36200 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725945AbfDWTmt (ORCPT ); Tue, 23 Apr 2019 15:42:49 -0400 Received: by mail-pl1-f193.google.com with SMTP id ck15so8031871plb.3 for ; Tue, 23 Apr 2019 12:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Nsc0vf7+PZJL2E4CRdH9ERV8IIFHqeF84cwVmHXei5s=; b=YUaS/fUe4UHuzVs1pA4/YXWwU//IJoC++NSu7zDetnMWk6Y3J9scuJYuTKGTdzsN0G uabYqt43KFbCWan/ArosLjJKtprw2p+3EH11ZHBk0B1Icb6KbZOslDBqzzW7HSkB7xz2 UGeKbev3DeqJarOKG0DbOW3yHWMzGVtjFXL92vMwyGRo6tbJ4L+8c6VT11ozNyIkfYF9 xgK59VFOyy1N3O+w4E/Y7u6vqb0DI12VKq1ZCHcPiYBXt82t6ymVSsZOpxwXJ2+YptgO CWMwqpIaK3UmHTj1sVECp9IIjeCuy0pfLfLk98iqt+oA3mtiV56Hd6mH79ZK2IloSUfz ZgDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Nsc0vf7+PZJL2E4CRdH9ERV8IIFHqeF84cwVmHXei5s=; b=U0BOfnzqwfWkzcOG2yBF33nRsSZ+1ElR/Q38FJhM55rcO+MkYMTKCa+qPMB8FT1C+/ zs/036+GAdWs6YoEqY3mkq56ELDIKI6Jt62FNzC+Yy8uAbQl2oLzcjYaU6JmsoJTBRK1 4Z+/tIJyRk2drhUAaTtifvUryBwUJZrwTjDFymHg7anHEZe8zzjnxYlW4dPgUkjA4zyg fvCjCXzhU/tEKbn1cTmH3Q6KOyhVQBV4XGwOxicibzKbrWRl3hsLUjL/jqFTrR6/4ZHk YKO5RR0u3JKEe0/I1aft6F/BoCI0f5Zfsxfx+QhWQfhupM0SEVC/TMIrYvEVKFDAFojn vBHQ== X-Gm-Message-State: APjAAAXug+2grAv+0alLvQaAml+VT34DJeRanlRYfYvfNw8OSFgndz0o /whHwI+6gqN8lmonhpL+a9/rNPhIbCHqLR3rtTJwng== X-Google-Smtp-Source: APXvYqybNmgILTnRlc83DagYUNKlCtDe1UnRfsXykVs4cFU8Rgu3Fw/kWIlVhs785WsXcujKFuJlJ+W1rBKvuWLNb3Q= X-Received: by 2002:a17:902:380c:: with SMTP id l12mr27760999plc.320.1556048567871; Tue, 23 Apr 2019 12:42:47 -0700 (PDT) MIME-Version: 1.0 References: <20190423190426.18720-1-natechancellor@gmail.com> <20190423193512.GP17719@sasha-vm> In-Reply-To: <20190423193512.GP17719@sasha-vm> From: Nick Desaulniers Date: Tue, 23 Apr 2019 12:42:36 -0700 Message-ID: Subject: Re: Backport of commit a75bb4eb9e565b9f5115e2e8c07377ce32cbe69a To: Sasha Levin Cc: Nathan Chancellor , Greg Kroah-Hartman , "# 3.4.x" , clang-built-linux@googlegroups.com Content-Type: text/plain; charset="UTF-8" Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Tue, Apr 23, 2019 at 12:35 PM Sasha Levin wrote: > > On Tue, Apr 23, 2019 at 12:04:21PM -0700, Nathan Chancellor wrote: > >Hi Greg and Sasha, > > > >Please apply this commit to 4.4 through 5.0 (patches are threaded in > >reply to this one), which will prevent Clang from emitting references > >to compiler runtime functions and doing some performance-killing > >optimization when using CONFIG_CC_OPTIMIZE_FOR_SIZE. > > > >Please let me know if I did something wrong or if there are any > >objections. > > This looks like a fix for a performance regression, which don't usually > end up in stable unless they are severe enough. > > This patch looks simple enough, and seeing peterz on it suggests to me > that this was significant enough for someone to notice. Is this really > the case, or is this just one of those %0.01 performance regression > things? I don't recall specific measurements, but when I tried Peter's suggestion and measured it, I wondered to myself how the initial patch was ever correct. The revert (what Nathan sent) should really be applied for folks building w/ Clang+CONFIG_CC_OPTIMIZE_FOR_SIZE=y, which is what some CrOS devices (and some Qualcomm BSPs) are doing. Rather than cherry pick this patch around to a bunch of different trees, it would be much better for this to land in -stable and for those trees not to diverge over this. Nathan, thank you for sending. -- Thanks, ~Nick Desaulniers