From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80530 invoked by alias); 27 Sep 2018 19:31:14 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 80513 invoked by uid 89); 27 Sep 2018 19:31:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_BL_SPAMCOP_NET,SPF_PASS autolearn=no version=3.3.2 spammy=SSE, H*RU:209.85.167.193, HX-Received:sk:l10-v6m, Hx-spam-relays-external:209.85.167.193 X-HELO: mail-oi1-f193.google.com Received: from mail-oi1-f193.google.com (HELO mail-oi1-f193.google.com) (209.85.167.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 27 Sep 2018 19:31:11 +0000 Received: by mail-oi1-f193.google.com with SMTP id m11-v6so3241415oic.2 for ; Thu, 27 Sep 2018 12:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5RMlasDJsTNPLCQ6emI+Zcn3/SyQhYvxonH78v0zt5w=; b=T6GfqgbaYbQq0qoVkrOWHMEf6m4aVfNCdzeyD8wSpTO9FxjgcIWaYou/3FAea6H052 +oSJctq4mBHSIzcdb8roXvK9t2GiNDIhxXItQHE10C94hIKushEWuJ72SeICVHNPK2GU 1y2Id9C09BCb1hRV5xRXUx1m+dgO8xCD/A9G48F/kPlxkAktUZpYtBFtOCDzZhjypzfL Oc4n6aP/4kachBY7/XB2BcF8g8rRtosmNHJ6BLtzKLbsYX7H/W1qEZIAHI4skV9ymzLV bRYd1tG8uOo3cd+XJRHvyRIzX69zvt5h9Y/mbmlFpNj9oe4B5LBVb5LhaxxoOPSmPW+Z fxkg== MIME-Version: 1.0 Received: by 2002:a4a:4d44:0:0:0:0:0 with HTTP; Thu, 27 Sep 2018 12:30:29 -0700 (PDT) In-Reply-To: References: <20180926181029.GA20898@intel.com> From: "H.J. Lu" Date: Thu, 27 Sep 2018 19:41:00 -0000 Message-ID: Subject: Re: RFC: [PATCH] x86: Add -mzero-caller-saved-regs=[skip|used|all] To: Richard Biener Cc: "szabolcs.nagy" , GCC Patches , nd , Uros Bizjak Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg01688.txt.bz2 On Thu, Sep 27, 2018 at 7:57 AM, Richard Biener wrote: > On Thu, Sep 27, 2018 at 3:16 PM H.J. Lu wrote: >> >> On Thu, Sep 27, 2018 at 6:08 AM, Szabolcs Nagy wrote: >> > On 26/09/18 19:10, H.J. Lu wrote: >> >> >> >> Add -mzero-caller-saved-regs=[skip|used|all] command-line option and >> >> zero_caller_saved_regs("skip|used|all") function attribue: >> >> >> >> 1. -mzero-caller-saved-regs=skip and zero_caller_saved_regs("skip") >> >> >> >> Don't zero caller-saved integer registers upon function return. >> >> >> >> 2. -mzero-caller-saved-regs=used and zero_caller_saved_regs("used") >> >> >> >> Zero used caller-saved integer registers upon function return. >> >> >> >> 3. -mzero-caller-saved-regs=all and zero_caller_saved_regs("all") >> >> >> >> Zero all caller-saved integer registers upon function return. >> >> >> >> Tested on i686 and x86-64 with bootstrapping GCC trunk and >> >> -mzero-caller-saved-regs=used as well as -mzero-caller-saved-regs=all >> >> enabled by default. >> >> >> > >> > from this description and the documentation it's >> > not clear to me what this tries to achieve. >> > >> > is it trying to prevent information leak? >> > or some pcs hack the caller may rely on? >> > >> > if it's for information leak then i'd expect such >> > attribute to be used on crypto code.. however i'd >> > expect crypto code to use simd registers as well, >> > so integer only cleaning needs explanation. >> >> The target usage is in Linux kernel. > > Maybe still somehow encode that in the option since it otherwise raises > expectations that are not met? > -mzero-call-clobbered-regs=used-int|all-int|skip|used-simd|used-fp,etc.? > and sorry() on unimplemented ones? Or simply zero also non-integer > regs the same way? I suppose > there isn't sth like vzeroupper that zeros all SIMD regs and completely? > The problem with SIMD regs is how to cover different ISAs, widths and number of SIMD regs. We need to generate at least 3 different code paths to clear SSE, AVX and AVX512 registers. -- H.J.