From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by sourceware.org (Postfix) with ESMTPS id D92EC3858D38 for ; Tue, 27 Feb 2024 08:47:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D92EC3858D38 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 D92EC3858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.135.223.131 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709023630; cv=none; b=BE7bB+YGiGQ+Q4dPBfIs6n+bjMM1RrSNHdyJa0kDAaIQfGSd0QtL6i/KNqAI+fYrFrFtMIyCLi3CRWK0fiCtD7l6iqwku/FElDAo1YlGpN8Ly81WBayGx9i8zALpjPdS0yP+3wfkFWwc8GEKDBMHYgySGQyd35q+ctoy0bOunQM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709023630; c=relaxed/simple; bh=AhPIRq67rxB6Vg6654pupI5TfRWx8yyc68xDlDjSUy0=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date: From:To:Subject:Message-ID:MIME-Version; b=DZOqtlPIiPDTRlzClFA4GkrrbNMn92EI5vBq/BdZUyqpvNhAyp4gdSCakjv45iuaik8WvpJT8c2iL9pi3fpkKVZustYsoISNAHo0AiWBYJvvNseOxIVeKPOyE347Vq5WXluZqfEldRvn4FonYD8MPei7hwgHk+mO+lr2423bEvE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [10.168.4.150] (unknown [10.168.4.150]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id E13C81F449; Tue, 27 Feb 2024 08:47:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1709023628; 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=q2+fjjWR9lFQt2PkJR4XMr3NxLsfpm6Hov+fETrdIGM=; b=lR1OO9e8Gt0WyGK68LziqSPv75H6m6HKu1aZ4SiTXcLdYGB7UOuOf8FWiyJnizvXQ7jfZR nBEiQdoQdhorCLylzElCc+L7PnPZ/8LwrrQEvShiaMzgm1tBli+KoeRc/ujSUxVkwOzTt8 jnTmA+2xBpp4z4aY4RGpI+bnUKKcKX4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1709023628; 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=q2+fjjWR9lFQt2PkJR4XMr3NxLsfpm6Hov+fETrdIGM=; b=eSImki8uTXTYpJMdAz7cuS0OvhsUzdeLs4TOdbNCZ94YJEnytxoN0SdHGOxzwDHXqkB16T 6W9OlL5wbJmZlKBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1709023627; 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=q2+fjjWR9lFQt2PkJR4XMr3NxLsfpm6Hov+fETrdIGM=; b=ZrouGr83Zz+otDuXe2U9xsvnCRGwNCsy94cLH1PGYKBrecOYjKyL3lnPUVWGll7wTasUMr 8ylfmYnByu6J1YaGU8+v/eF3i61FQcKv3/is/Lj8MfJukpnNkqQHdiA4QyaEl3YkLFwMtt FwUF3jMKC5ApJMdJ+lujrqHaj0UQw7Y= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1709023627; 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=q2+fjjWR9lFQt2PkJR4XMr3NxLsfpm6Hov+fETrdIGM=; b=WrbjEaw9ck6gFLqdrcQ57BG5YSifuUGJpRNTGmNHM0c4EJ/zQ/NIDZ2S74ZdO6QmD4qdtI vMGP/j2ByW2x18Aw== Date: Tue, 27 Feb 2024 09:47:07 +0100 (CET) From: Richard Biener To: "Andre Vieira (lists)" cc: gcc-patches@gcc.gnu.org, Richard.Sandiford@arm.com Subject: Re: [PATCH 1/3] vect: Pass stmt_vec_info to TARGET_SIMD_CLONE_USABLE In-Reply-To: Message-ID: References: <20240130143132.9575-1-andre.simoesdiasvieira@arm.com> <20240130143132.9575-2-andre.simoesdiasvieira@arm.com> <47e1aeb2-94ac-4733-b49f-ea97932cc49f@arm.com> <545r8s73-675p-4o48-sr66-q6956nqp6r6p@fhfr.qr> <3rq8sn71-8188-o4rq-9spp-q9spn98163q5@fhfr.qr> <359e8112-65c9-40b1-9566-aa31165c05e8@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Authentication-Results: smtp-out2.suse.de; none X-Spam-Level: X-Spam-Score: -1.09 X-Spamd-Result: default: False [-1.09 / 50.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(3.00)[1.000]; NEURAL_HAM_LONG(-0.99)[-0.995]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FUZZY_BLOCKED(0.00)[rspamd.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; BAYES_HAM(-3.00)[100.00%] X-Spam-Status: No, score=-5.0 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: On Mon, 26 Feb 2024, Andre Vieira (lists) wrote: > > > On 05/02/2024 09:56, Richard Biener wrote: > > On Thu, 1 Feb 2024, Andre Vieira (lists) wrote: > > > >> > >> > >> On 01/02/2024 07:19, Richard Biener wrote: > >>> On Wed, 31 Jan 2024, Andre Vieira (lists) wrote: > >>> > >>> > >>> The patch didn't come with a testcase so it's really hard to tell > >>> what goes wrong now and how it is fixed ... > >> > >> My bad! I had a testcase locally but never added it... > >> > >> However... now I look at it and ran it past Richard S, the codegen isn't > >> 'wrong', but it does have the potential to lead to some pretty slow > >> codegen, > >> especially for inbranch simdclones where it transforms the SVE predicate > >> into > >> an Advanced SIMD vector by inserting the elements one at a time... > >> > >> An example of which can be seen if you do: > >> > >> gcc -O3 -march=armv8-a+sve -msve-vector-bits=128 -fopenmp-simd t.c -S > >> > >> with the following t.c: > >> #pragma omp declare simd simdlen(4) inbranch > >> int __attribute__ ((const)) fn5(int); > >> > >> void fn4 (int *a, int *b, int n) > >> { > >> for (int i = 0; i < n; ++i) > >> b[i] = fn5(a[i]); > >> } > >> > >> Now I do have to say, for our main usecase of libmvec we won't have any > >> 'inbranch' Advanced SIMD clones, so we avoid that issue... But of course > >> that > >> doesn't mean user-code will. > > > > It seems to use SVE masks with vector(4) and the > > ABI says the mask is vector(4) int. You say that's because we choose > > a Adv SIMD clone for the SVE VLS vector code (it calls _ZGVnM4v_fn5). > > > > The vectorizer creates > > > > _44 = VEC_COND_EXPR ; > > > > and then vector lowering decomposes this. That means the vectorizer > > lacks a check that the target handles this VEC_COND_EXPR. > > > > Of course I would expect that SVE with VLS vectors is able to > > code generate this operation, so it's missing patterns in the end. > > > > Richard. > > > > What should we do for GCC-14? Going forward I think the right thing to do is > to add these patterns. But I am not even going to try to do that right now and > even though we can codegen for this, the result doesn't feel like it would > ever be profitable which means I'd rather not vectorize, or well pick a > different vector mode if possible. > > This would be achieved with the change to the targethook. If I change the hook > to take modes, using STMT_VINFO_VECTYPE (stmt_vinfo), is that OK for now? Passing in a mode is OK. I'm still not fully understanding why the clone isn't fully specifying 'mode' and if it does not why the vectorizer itself can not disregard it. >From the past discussion I understood the existing situation isn't as bad as initially thought and no bad things happen right now? Thanks, Richard.