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.129.124]) by sourceware.org (Postfix) with ESMTPS id B29D83858D37 for ; Thu, 20 Apr 2023 16:02:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B29D83858D37 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=1682006577; 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=NYevJiAAT85oaiB4S7ClLNKGgerLAaC2N8gLDMrbPnc=; b=Tjt17wFnBXTnQV5bEHB311rxtjVk6rnn+q5M3qgRvMs9Nf4Ws+SI78KUEFFQYlaprmeW3L PxMJexd367PT+/uDLJhckYvPGe1uELykJVQBat6TtrqiAbR02cgQz/HZp/EYbRBnUeEEmA UkZGBWlZAQYx4pKDOXyNFidwZVtae1Q= 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-437-r4znlA5XPtSPs2JqhWA-Qg-1; Thu, 20 Apr 2023 12:02:53 -0400 X-MC-Unique: r4znlA5XPtSPs2JqhWA-Qg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1DC35811E7C; Thu, 20 Apr 2023 16:02:53 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.194.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CF09151E3; Thu, 20 Apr 2023 16:02:52 +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 33KG2oXE1304931 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 20 Apr 2023 18:02:50 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 33KG2n0J1303053; Thu, 20 Apr 2023 18:02:49 +0200 Date: Thu, 20 Apr 2023 18:02:48 +0200 From: Jakub Jelinek To: "Andre Vieira (lists)" Cc: "gcc-patches@gcc.gnu.org" , Richard Biener , richard.sandiford@arm.com Subject: Re: [RFC 0/X] Implement GCC support for AArch64 libmvec Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 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=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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 Thu, Apr 20, 2023 at 04:22:50PM +0100, Andre Vieira (lists) wrote: > > I don't see a good reason for dropping the extension("scalable"). > > The problem is that since the base spec requires a simdlen clause, > > GCC should in general raise an error if simdlen is omitted. > Where can you find this in the specs? I tried to find it but couldn't. > > Leaving out simdlen in a 'omp declare simd' I assume is OK, our vector ABI > defines behaviour for this. But I couldn't find what it meant for a omp > declare variant, obviously can't be the same as for declare simd, as that is > defined to mean 'define a set of clones' and only one clone can be > associated to a declare variant. For missing simdlen on omp declare simd, OpenMP 5.2 says [202:14-15]: "If a SIMD version is created and the simdlen clause is not specified, the number of concurrent arguments for the function is implementation defined." Nobody says it must be a constant when not specified, when specified it has to be a constant. declare variant is function call specialization based on lots of different aspects. If you specify simd among construct selectors, then the implementation is allowed (and kind of expected but not currently implemented in GCC) to change the calling convention based on the declare simd ABIs, but again, simdlen might be specified (then it has to have constant number in it) or not, then I bet it is supposed to be derived from the actual differences in the calling convention to which match it is. But as I said, this part isn't implemented yet even on other targets. Jakub