From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93571 invoked by alias); 2 Sep 2018 14:57:41 -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 93544 invoked by uid 89); 2 Sep 2018 14:57:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.4 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_3,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=retest, Hmm, H*r:0700 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 02 Sep 2018 14:57:39 +0000 Received: from svr-orw-mbx-04.mgc.mentorg.com ([147.34.90.204]) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1fwTom-0001Ym-4z from Cesar_Philippidis@mentor.com ; Sun, 02 Sep 2018 07:57:36 -0700 Received: from [127.0.0.1] (147.34.91.1) by SVR-ORW-MBX-04.mgc.mentorg.com (147.34.90.204) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 2 Sep 2018 07:57:33 -0700 Subject: Re: [patch,nvptx] Basic -misa support for nvptx To: Tom de Vries , "gcc-patches@gcc.gnu.org" References: From: Cesar Philippidis Message-ID: <77123011-edbc-5cbd-ad47-22daf9c55273@codesourcery.com> Date: Sun, 02 Sep 2018 14:57:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-SW-Source: 2018-09/txt/msg00050.txt.bz2 On 09/01/2018 12:04 PM, Tom de Vries wrote: > On 08/31/2018 04:14 PM, Cesar Philippidis wrote: >> Is this patch OK for trunk? >> > > Well, how did you test this ( > https://gcc.gnu.org/contribute.html#patches : "Bootstrapping and > testing. State the host and target combinations you used to do proper > testing as described above, and the results of your testing.") ? I tested the standalone nvptx compiler. I'll retest with libgomp with -misa=sm_35. Bootstrapping won't help much here, unfortunately. >> +++ b/gcc/testsuite/gcc.target/nvptx/atomic_fetch-1.c >> @@ -0,0 +1,24 @@ >> +/* Test the nvptx atomic instructions for __atomic_fetch_OP for SM_35 >> + targets. */ >> + >> +/* { dg-do compile } */ >> +/* { dg-options "-O2 -misa=sm_35" } */ >> + >> +int >> +main() >> +{ >> + unsigned long long a = ~0; >> + unsigned b = 0xa; >> + >> + __atomic_fetch_add (&a, b, 0); >> + __atomic_fetch_and (&a, b, 0); >> + __atomic_fetch_or (&a, b, 0); >> + __atomic_fetch_xor (&a, b, 0); >> + >> + return a; >> +} >> + >> +/* { dg-final { scan-assembler "atom.add.u64" } } */ >> +/* { dg-final { scan-assembler "atom.b64.and" } } */ >> +/* { dg-final { scan-assembler "atom.b64.or" } } */ >> +/* { dg-final { scan-assembler "atom.b64.xor" } } */ >> -- 2.17.1 >> > > Hmm, the add.u64 vs b64.and looks odd (and the scan-assembler-not > testcase does not use this difference, so that needs to be fixed, or for > bonus points, changed into a scan-assembler testcase). > > The documentation uses "op.type", we should fix the compiler to emit > that consistently. Separate patch that fixes that pre-approved. ACK. I think there are a lot of other cases like that in the BE. > This is ok (with, as I mentioned above, the SI part split off into a > separate patch), on the condition that you test libgomp with > -foffload=-misa=sm_35. Thanks, Cesar