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 A26FC3858297 for ; Wed, 14 Sep 2022 08:34:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A26FC3858297 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=1663144476; 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=dUbKdSJMZM1Vkt1JHx29mMIgSl3J+pAIJnuk49XpeQc=; b=bAVgKznZEnhypcx3rsJR73IXMJZPgGMXJwROvPisAOVZWrhHBUdyfTDTDfa76rDbnynV2x O0VhzoGZB7R93kUR8rsnfDIXOQoyyDYXyDqXX3X8ak36mU23VbtTermdYIO+e7eh3KmtyG FVQxLprI2bxlDVUjxqpIGwelpmILq5I= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-627-Ar_wUgh8NGmFHdituzfCtw-1; Wed, 14 Sep 2022 04:34:35 -0400 X-MC-Unique: Ar_wUgh8NGmFHdituzfCtw-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 A10EE3C0D18E; Wed, 14 Sep 2022 08:34:34 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.41]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 44F1249BB60; Wed, 14 Sep 2022 08:34:34 +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 28E8YVba1975111 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 14 Sep 2022 10:34:31 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 28E8YTvx1975110; Wed, 14 Sep 2022 10:34:29 +0200 Date: Wed, 14 Sep 2022 10:34:29 +0200 From: Jakub Jelinek To: Richard Biener Cc: Andrew Stubbs , gcc-patches@gcc.gnu.org Subject: Re: [PATCH 3/3] vect: inbranch SIMD clones Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: 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.5 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 08:09:08AM +0000, Richard Biener wrote: > Are nested functions a thing for OpenMP? But yes, punt on them > for now. For Fortran certainly because they are part of the language, for C too because they are GNU extension. But declare simd is mostly best effort, so we can at least for now punt. > I agree that a conditional call should be explicit, but the above is > only transitional between if-conversion and vectorization, right? > Do we support indirect calls here? As Jakub says one possibility > is to do > > .IFN_COND/MASK_CALL (fn-addr, condition/mask, ...) > > another would be > > fnptr = cond ? fn : &nop_call; > (*fnptr) (...); > > thus replace the called function with conditional "nop". How > to exactly represent that NOP probably isn't too important > when it's transitional until vectorization only, even NULL > might work there. Of course having the function address > in a computation might confuse parts of the vectorizer. OTOH > it allows to keep the original call (and the chain and any > other info we'd have to preserve otherwise). On the ifn one can preserve those too and the advantage is that it would be just one command rather than 2, but I'm not opposed to the other way either. Jakub