From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D78F33858D20; Mon, 8 Apr 2024 12:32:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D78F33858D20 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1712579534; bh=T1YQEYDUEaTBcnWMfiXqQRrJCUyGYmbP7STWwdJeGoU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=r2K6P2a6S8JICw4UvHIoC0FtXQ8KuLuKrLzhKYkYaZSL87PFQfZt2KJIFp2a34u9h mi5ehG78uzdBUsqhkVoL0I4q9i/AJiIjWwtzPzvdmQs7PUKNIpmLNEuP3MMH3C37rI vM8BtFPmwwQVGWdKrWapUom7sk/9I7V+oASzdYUc= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/114635] OpenMP reductions fail dependency analysis Date: Mon, 08 Apr 2024 12:32:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: missed-optimization, openmp X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114635 --- Comment #4 from Jakub Jelinek --- The OpenMP safelen clause argument is a scalar integer, so using poly_int f= or something that must be an int doesn't make sense. Though, the above testcase actually doesn't use safelen clause, so safelen = is there effectively infinity. The issue is how we represent the clauses like reduction on simd. The design is that they are represented as initially large magic "omp simd array" arrays with constant number of iterations derived from the maximum possible vectorization factor, and then the vectorizer either shrinks those= two the actual vectorization factor (if different from the old constant) or to = [1] array if vectorization wasn't possible and we've in fact used vectorization factor of 1. Now, with SVE/RISCV vectors the actual vectorization factor is a poly_int rather than constant. One possibility would be to use VLA arrays in those cases, but then it will be hard to undo that later, or allow both shrinking= and growing the arrays and even turning them into VLA-like ones.=