From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 2AA1E38582AF for ; Wed, 14 Sep 2022 18:12:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2AA1E38582AF Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663179169; 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:in-reply-to:in-reply-to: references:references; bh=1wA38LRWhucIb8ZYS+DQGU7hcsu38i8OR7NrQYojk44=; b=LeWxWzdbe+HJxo83nseWMADz7NEmMUBG4sDhtVbBBpy2tx92oDEAB2uNCeM7lmC+4zEb81 1cWy34mMjaNsCwwzze+ixiajJr40eADfUiuNBGUUdwmpCjtptY+UgIvbtDnCdVymXgLHBm eUCZFCFT3EQ9r53mtcg00lkt/lZoSAo= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-404-AjF5NlX6N_KGDBeRfqe3rQ-1; Wed, 14 Sep 2022 14:12:48 -0400 X-MC-Unique: AjF5NlX6N_KGDBeRfqe3rQ-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 45129833948; Wed, 14 Sep 2022 18:12:48 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.194]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 07228492CA2; Wed, 14 Sep 2022 18:12:47 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 28EICjPr1976802 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 14 Sep 2022 20:12:45 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 28EICiiO1976801; Wed, 14 Sep 2022 20:12:44 +0200 Date: Wed, 14 Sep 2022 20:12:44 +0200 From: Jakub Jelinek To: Sandra Loosemore Cc: "gcc-patches@gcc.gnu.org" Subject: Re: OpenMP: Generate SIMD clones for functions with "declare target" Message-ID: Reply-To: Jakub Jelinek References: <0b64e323-63f9-e4b7-eb7f-83f3b5e3125b@codesourcery.com> MIME-Version: 1.0 In-Reply-To: <0b64e323-63f9-e4b7-eb7f-83f3b5e3125b@codesourcery.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Sep 14, 2022 at 11:32:11AM -0600, Sandra Loosemore wrote: > This patch is part of the ongoing effort to find more SIMD optimization > opportunities in OpenMP code. Here we are looking for functions that have > the "omp declare target" attribute that are also suitable candidates for > automatic SIMD cloning. I've made the filter quite conservative, but maybe > it could be improved with some further analysis. I added a command-line > flag to disable this in case it is buggy :-P or leads to excessive code > bloat without improving performance in some cases, otherwise the SIMD clones > are generated in the same way and at the same optimization levels as the > existing simdclone pass. > > I had to modify the TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN hook to > add a boolean argument to control diagnostics, since GCC shouldn't complain > about types the target doesn't support in cases where the user didn't > explicitly ask for clones to be created. I tested on > x86_64-linux-gnu-amdgcn, plain x86_64-linux-gnu, and aarch64-linux-gnu to > get coverage of all 3 backends that implement this hook. OK for mainline? declare simd is an ABI relevant declarative directive, while declare target is not, all the latter does is say whether the function should be also (or only) compilable on an offloading target. Creating simd clones under some option for random declare target functions (note, declare target is partly auto-discovered property) is perhaps fine for functions not exported from the translation unit where it is purely an optimization, but otherwise it is a significant ABI problem, you export whole new bunch of new exports on the definition side and expect those to be exported on the use side. If you compile one TU with -fopenmp-target-simd-clone and another one without it, program might not link anymore. And worse, as it is decided based on the exact implementation of the function, I assume you can't do that automatically for functions not defined locally, but whether something has simd clones or not might change over time based on how you change the implementation. Say libfoo.so exports a declare target function foo, which is initially implemented without say using inline asm (or calling one of the "bad" functions or using exceptions etc.), but then a bugfix comes and needs to use inline asm or something else in the implementation. Previously libfoo.so would export the simd clones, but now it doesn't, so the ABI of the library changes. If it is pure optimization thing and purely keyed on the definition, all the simd clones should be local to the TU, never exported from it. Jakub