From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13022 invoked by alias); 4 Feb 2020 11:42:23 -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 13014 invoked by uid 89); 4 Feb 2020 11:42:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy= X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-2.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 04 Feb 2020 11:42:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580816540; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lprczrevJF82ixUqinpQExpFVeEmHAxPc/UEPyxHCQ0=; b=eGuJMB567DwYWcN/8Rn7rSgENcv2ER1tdd5qyfRco7vC5yLMUuVxnnjGBsv9skr2MPXuiB 6SAbRh8WuYgM1XYRX5GL8dsku7lE3kxy9dBMKckFTqaOxaIIeEgTKiWfXMMOXewwQwk53T W5SnuqeMtJhktU8mcAipeGbbFOyJllw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-292-Z1Ljv87yMXa2XoaR85hxjQ-1; Tue, 04 Feb 2020 06:42:16 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 70442DBA7; Tue, 4 Feb 2020 11:42:15 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-51.ams2.redhat.com [10.36.116.51]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0651B83865; Tue, 4 Feb 2020 11:42:14 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id 014BgCbZ020060; Tue, 4 Feb 2020 12:42:13 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id 014BgBW5020059; Tue, 4 Feb 2020 12:42:11 +0100 Date: Tue, 04 Feb 2020 11:42:00 -0000 From: Jakub Jelinek To: Jonathan Yong <10walls@gmail.com> Cc: Uros Bizjak , "gcc-patches@gcc.gnu.org" Subject: [PATCH] i386: Make xmm16-xmm31 call used even in ms ABI Message-ID: <20200204114211.GP17695@tucnak> Reply-To: Jakub Jelinek References: <20200204093921.GN17695@tucnak> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00175.txt.bz2 Hi! On Tue, Feb 04, 2020 at 11:16:06AM +0100, Uros Bizjak wrote: > I guess that Comment #9 patch form the PR should be trivially correct, > but althouhg it looks obvious, I don't want to propose the patch since > I have no means of testing it. I don't have means of testing it either. https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=3Dvs= -2019 is quite explicit that [xyz]mm16-31 are call clobbered and only xmm6-15 (low 128-bits only) are call preserved. Jonathan, could you please test this if it is sufficient to just change CALL_USED_REGISTERS or if e.g. something in the pro/epilogue needs tweaking too? Thanks. We are talking e.g. about /* { dg-options "-O2 -mabi=3Dms -mavx512vl" } */ typedef double V __attribute__((vector_size (16))); void foo (void); V bar (void); void baz (V); void qux (void) { V c; { register V a __asm ("xmm18"); V b =3D bar (); asm ("" : "=3Dx" (a) : "0" (b)); c =3D a; } foo (); { register V d __asm ("xmm18"); V e; d =3D c; asm ("" : "=3Dx" (e) : "0" (d)); baz (e); } } where according to the MSDN doc gcc incorrectly holds the c value in xmm18 register across the foo call; if foo is compiled by some Microsoft compiler (or LLVM), then it could clobber %xmm18. If all xmm18 occurrences are changed to say xmm15, then it is valid to hold the 128-bit value across the foo call (though, surprisingly, LLVM saves it into stack anyway). 2020-02-04 Uro=C5=A1 Bizjak * config/i386/config/i386/i386.h (CALL_USED_REGISTERS): Make xmm16-xmm31 call-used even in 64-bit ms-abi. --- gcc/config/i386/config/i386/i386.h.jj 2020-01-22 10:19:24.199221986 +01= 00 +++ gcc/config/i386/config/i386/i386.h 2020-02-04 12:09:12.338341003 +0100 @@ -1128,9 +1128,9 @@ extern const char *host_detect_local_cpu /*xmm8,xmm9,xmm10,xmm11,xmm12,xmm13,xmm14,xmm15*/ \ 6, 6, 6, 6, 6, 6, 6, 6, \ /*xmm16,xmm17,xmm18,xmm19,xmm20,xmm21,xmm22,xmm23*/ \ - 6, 6, 6, 6, 6, 6, 6, 6, \ + 1, 1, 1, 1, 1, 1, 1, 1, \ /*xmm24,xmm25,xmm26,xmm27,xmm28,xmm29,xmm30,xmm31*/ \ - 6, 6, 6, 6, 6, 6, 6, 6, \ + 1, 1, 1, 1, 1, 1, 1, 1, \ /* k0, k1, k2, k3, k4, k5, k6, k7*/ \ 1, 1, 1, 1, 1, 1, 1, 1 } =20 Jakub