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 CCFAB38582AF for ; Wed, 14 Sep 2022 17:55:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CCFAB38582AF 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=1663178116; 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=lW3vo94vt0bj7CkGnAiO5T0KPLUmzDtsg9p+jZy+qU4=; b=EJH1JMf31ZmZ2xigUT56v1yRPzCzFfA0/MGcij4Fv8ebX4zfqjxtYxcvt1p+fb18craw/A ryrZKgonyzqYoJFR8EL5FAvVi3z1FKFKsRw9hqKBGVCDJ5CZ/0EES7BIPZMKk7FqjBGcmQ WlJDPCpn2mYGQ6mwe1gQ/tAgl2ehJtE= 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-580-BBq47LELPWCl4ZxfLnVBlg-1; Wed, 14 Sep 2022 13:55:15 -0400 X-MC-Unique: BBq47LELPWCl4ZxfLnVBlg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0FA20294EDE4; Wed, 14 Sep 2022 17:55:15 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.194]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C62962166B29; Wed, 14 Sep 2022 17:55:14 +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 28EHtBCJ1976765 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 14 Sep 2022 19:55:11 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 28EHtAYZ1976764; Wed, 14 Sep 2022 19:55:10 +0200 Date: Wed, 14 Sep 2022 19:55:10 +0200 From: Jakub Jelinek To: Sandra Loosemore Cc: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH] OpenMP: Enable vectorization in all OpenMP loops Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 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.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LIKELY_SPAM_BODY,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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:31:34AM -0600, Sandra Loosemore wrote: > GCC presently enables the loop vectorizer at lower optimization levels for > OpenMP loops with the "simd" specifier than it does for loops without it. > The "simd" specifier isn't defined to be purely an optimization hint to the > compiler; it also has semantic effects like changing the privatization of > the loop variable. It seems reasonable to decouple the additional > vectorization from those semantic effects and apply it also to work-sharing > loops without the "simd" specifier at the same optimization levels. > > I've tested this patch on x86_64-linux-gnu-amdgcn, plain x86_64-linux-gnu, > and aarch64-linux-gnu. OK for mainline? I don't understand this. Isn't -ftree-loop-optimize on by default at all optimization levels? Why this would be a good idea for say -O0, or -Og, -Os, or -Oz? People want the code be debuggable with -O0 or -Og, it doesn't help if it is vectorized (not sure if the vectorizer gate is even reached in that case though), and for -Os or -Oz want small code, which vectorized code typically is not. And the vectorizer is on by default for -O2 and higher, so is this just about -O1? The reason for setting force_vectorize for simd directive is that the user asks explicitly for it. For other constructs we can just guess on user intents. For simd directive the user also guarantees that there aren't inter-iteration dependencies that would prevent vectorization, but that is expressed in loop->safelen and loop->simdlen, for other loops we don't have such guarantees, so the compiler just needs to analyze if they are vectorizable. But doesn't gcc already do that for -O2/-O3 by default? As for loop->safelen, I think we might set it in some cases for other OpenMP constructs, like distribute without dist_schedule or worksharing-loops with certain set of clauses (I think without schedule clause). Jakub