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 EC7253858C50 for ; Fri, 20 Jan 2023 20:02:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EC7253858C50 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=1674244946; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=oKfG4BGP0b1+j6Xcmz0fubknRNQZIUkV4XPkWsIqeCM=; b=ZN1G8JX8T9ibfF5pgnh2OenZcUDrTBHBIiRXvEpIIg8BGbHyYKVIW+0UVIk07XMDQLi7Ou +SYhxBtdejGjzgZ/tao0ixRDAp3QDrWBssucf8V+gnHCIPQ74/FZvHR0Pwev24p4sXSFg1 HwJ/g7ep5X4luePVQjfw+QUYacJi6nY= 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-221-BNBk5B4DMC2I4ppNJX7p8w-1; Fri, 20 Jan 2023 15:02:22 -0500 X-MC-Unique: BNBk5B4DMC2I4ppNJX7p8w-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D53F7385F36B; Fri, 20 Jan 2023 20:02:21 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 926052026D68; Fri, 20 Jan 2023 20:02:21 +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 30KK2IfX3389910 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 20 Jan 2023 21:02:18 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 30KK2HRQ3389909; Fri, 20 Jan 2023 21:02:17 +0100 Date: Fri, 20 Jan 2023 21:02:17 +0100 From: Jakub Jelinek To: Tobias Burnus , gcc-patches , fortran Subject: Re: [Patch] OpenMP/Fortran: Partially fix non-rect loop nests [PR107424] Message-ID: Reply-To: Jakub Jelinek References: <18c3aed8-71dd-9b7f-6c7c-da529876d3f5@codesourcery.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 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=-2.7 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 autolearn=unavailable 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 Fri, Jan 20, 2023 at 07:00:18PM +0100, Jakub Jelinek via Gcc-patches wrote: > Though, I wonder if we shouldn't for GCC 13 just sorry_at about > steps other than constant 1/-1 (in both outer loop with var-outer referenced > in inner loop and on inner loop that references it) and for the !VAR_P case > actually handle it if step 1/-1 by using simple like translation just with > an artificial iterator. As for the steps other than constant 1/-1, we have 5 cases: do i = x, y, 25 or do i = 12, 72, z or do i = x, y, -42 or do i = 42, -10, z or do i = x, y, z The 1st and 3rd are with constant step, 2nd and 4th with constant lower and upper bounds and the last one has step and at least one of the bounds non-constant. I wonder if in the light of e.g. PR108431 which says that do i = -huge(i), huge(i) is invalid (well, that one would be very wrong even from OpenMP POV because computing number of iterations definitely overflows) and the fact that we handle step 1 and -1 the simple way do do i = huge(i) - 10, huge(i) will not work either, I wonder if even do i = huge(i) - 5, huge(i) - 1, 2 is undefined (similar reasoning, if i after loop needs to be set to the huge(i) + 1 it is signed integer overflow). If yes, then perhaps at least the first 4 cases could be easily handled (perhaps for GCC 13 just if clauses->non_rectangular only) as for (i = x; i <= y; i += 25) or for (i = 12; i <= 72; i += z) or for (i = x; i >= y; i -= 42) or for (i = 42; i >= -10; i += z) If those give equivalent behavior, then that would mean a sorry only for the last case - the problem is that we then don't know at compile time the direction. Though perhaps even for that case we could play tricks, handle do i = x, y, z as if (z > 0) a = x, b = y, c = z; else a = INT_MIN, b = too_lazy_to_compute_that_now, c = -z; for (counter = a; counter <= b; counter += c) { if (z > 0) i = counter; else i = counter - (unsigned) INT_MAX; } If that works, we'd need to figure also out how to handle that in the non-rect cases. But the m1 * var-outer + a1 and m2 * var-outer + a2 factors can be non-constant invariants, so again we could compute something for them depending on if the outer or inner step was positive or negative. Jakub