From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id 32A843858D1E for ; Tue, 31 Oct 2023 07:59:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 32A843858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 32A843858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:67c:2178:6::1c ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698739168; cv=none; b=iRLri4f8eavV7YpW8yMcxEORGM24ZELdtZgiIM7ExavjX7ays13wGOuuN6xH6xVaGVyw5ymeOgW/LI43oTABpiTQjWfGg47vWbPOycxLUfUTRXzhnVomi8gklf/gj2Rp/ZgJFTPm55rOYTS6hjk7klhkoXo6zAGLwfx2MSlB/Ao= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698739168; c=relaxed/simple; bh=tTt2IpwRLKtUxcBhBcPX79delvnKl7I3NmKYDMYFIrI=; h=DKIM-Signature:DKIM-Signature:Date:From:To:Subject:Message-ID: MIME-Version; b=MEDiKhm1SKjPg+O3koDwZqlIOBob3wO+NPrzYtFPFRY074IP3xeFvFgIUuSkp3sjQ2zNbUi5ixqjTKVZnoencuO0sa5yM3J3cVkDoivl/dyU+uDKnKXtvoZqgkV+91mVtnF5HxoUwZpeFLIy/OumCkv5T5mwqy6+evfxc2yG4rQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id AD1C921863; Tue, 31 Oct 2023 07:59:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1698739165; h=from:from:reply-to: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=dpHMLa7l30gy6Onx0DPDe5fc60Cfj+RF14JkVn79peI=; b=bxSqotj/aJVYlU4RYNtMr3JwWWwPqfPSDH81AyHvaWJMRytE1y9RL4poRpr12dBravup0b xFnrpr3s186ZaiYA2NQbBBsQa6K2QlbO6VIH+8MEBYj8MLvq4z3chAIMLKurCHNnjQyk7L Z+IF/SF0He4e+iDIWlw1qtxgJo1z1Gw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1698739165; h=from:from:reply-to: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=dpHMLa7l30gy6Onx0DPDe5fc60Cfj+RF14JkVn79peI=; b=tRsJyryurvjOeCQMEwOIrKqR+70OJm/wP+Ds2M63zj9REaQu0WX6nR0YXVbnR/S/YKO092 VJNyVMdbKqMAtoDg== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 61CCB2C153; Tue, 31 Oct 2023 07:59:25 +0000 (UTC) Date: Tue, 31 Oct 2023 07:59:25 +0000 (UTC) From: Richard Biener To: "Andre Vieira (lists)" cc: gcc-patches@gcc.gnu.org, Richard Sandiford , "jakub@redhat.com" Subject: Re: [PATCH6/8] omp: Reorder call for TARGET_SIMD_CLONE_ADJUST (was Re: [PATCH7/8] vect: Add TARGET_SIMD_CLONE_ADJUST_RET_OR_PARAM) In-Reply-To: <8bc378c8-b87d-4fa6-a8f6-7665612352d8@arm.com> Message-ID: References: <73b53052-c3a4-4028-2836-ade419431eda@arm.com> <7fc775ba-378a-483f-b318-6b6b4aff92a6@arm.com> <8bc378c8-b87d-4fa6-a8f6-7665612352d8@arm.com> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1609957120-1974366943-1698739165=:8772" X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,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: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1609957120-1974366943-1698739165=:8772 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Wed, 18 Oct 2023, Andre Vieira (lists) wrote: > This patch moves the call to TARGET_SIMD_CLONE_ADJUST until after the > arguments and return types have been transformed into vector types. It also > constructs the adjuments and retval modifications after this call, allowing > targets to alter the types of the arguments and return of the clone prior to > the modifications to the function definition. > > Is this OK? OK (I was hoping for Jakub to have a look). Thanks, Richard. > gcc/ChangeLog: > > * omp-simd-clone.cc (simd_clone_adjust_return_type): Hoist out > code to create return array and don't return new type. > (simd_clone_adjust_argument_types): Hoist out code that creates > ipa_param_body_adjustments and don't return them. > (simd_clone_adjust): Call TARGET_SIMD_CLONE_ADJUST after return > and argument types have been vectorized, create adjustments and > return array after the hook. > (expand_simd_clones): Call TARGET_SIMD_CLONE_ADJUST after return > and argument types have been vectorized. > > On 04/10/2023 13:40, Andre Vieira (lists) wrote: > > > > > > On 04/10/2023 11:41, Richard Biener wrote: > >> On Wed, 4 Oct 2023, Andre Vieira (lists) wrote: > >> > >>> > >>> > >>> On 30/08/2023 14:04, Richard Biener wrote: > >>>> On Wed, 30 Aug 2023, Andre Vieira (lists) wrote: > >>>> > >>>>> This patch adds a new target hook to enable us to adapt the types of > >>>>> return > >>>>> and parameters of simd clones.  We use this in two ways, the first one > >>>>> is > >>>>> to > >>>>> make sure we can create valid SVE types, including the SVE type > >>>>> attribute, > >>>>> when creating a SVE simd clone, even when the target options do not > >>>>> support > >>>>> SVE.  We are following the same behaviour seen with x86 that creates > >>>>> simd > >>>>> clones according to the ABI rules when no simdlen is provided, even if > >>>>> that > >>>>> simdlen is not supported by the current target options.  Note that this > >>>>> doesn't mean the simd clone will be used in auto-vectorization. > >>>> > >>>> You are not documenting the bool parameter of the new hook. > >>>> > >>>> What's wrong with doing the adjustment in TARGET_SIMD_CLONE_ADJUST? > >>> > >>> simd_clone_adjust_argument_types is called after that hook, so by the time > >>> we > >>> call TARGET_SIMD_CLONE_ADJUST the types are still in scalar, not vector.  > >>> The > >>> same is true for the return type one. > >>> > >>> Also the changes to the types need to be taken into consideration in > >>> 'adjustments' I think. > >> > >> Nothing in the three existing implementations of TARGET_SIMD_CLONE_ADJUST > >> relies on this ordering I think, how about moving the hook invocation > >> after simd_clone_adjust_argument_types? > >> > > > > But that wouldn't change the 'ipa_param_body_adjustments' for when we have a > > function definition and we need to redo the body. > >> Richard. > >> > >>> PS: I hope the subject line survived, my email client is having a bit of a > >>> wobble this morning... it's what you get for updating software :( > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg) ---1609957120-1974366943-1698739165=:8772--