From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C45E2386F434; Tue, 21 Apr 2020 06:42:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C45E2386F434 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1587451350; bh=dBoQjmqYdUsZgVzT61Pvjvlr+joahpceH0RtJINTWsU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SnKY7SYcfNahc6zbcTgzMIA+RdGMsafRaa7pKIFxp5vZu29HlLeG8hwB8zs4FgS/0 gVLJOUvXEWzx/kr7hopkAi2NxENqDVqrqV9XOVFek3G9S3owgkqn5kXxmK4Aqeg2KI KDgP/KL4wp2JWIQ1NUyVBnnOdlm6vtNDLVL9u3t8= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/90591] Avoid unnecessary data transfer out of OMP construct Date: Tue, 21 Apr 2020 06:42:30 +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: 10.0 X-Bugzilla-Keywords: openacc, openmp X-Bugzilla-Severity: enhancement X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: sandra at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 06:42:30 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D90591 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hubicka at gcc dot gnu.org, | |jamborm at gcc dot gnu.org --- Comment #3 from Richard Biener --- I think while relying on a robust IPA analysis and optimization framework sounds appealing the problem is _much_ easier solved before OMP/OACC loweri= ng and I would strongly suggest to tackle the problem from that side if you wa= nt a workable solution in a timely manner. I realize that has a plethora of its own issues, first of all it seems the respective lowering is done _very_ early - aka the optimization would need to be part of omplower? (I see .omp_data_i constructed there) So what you need is liveness and def/use analysis on high GIMPLE which I think is straight-forward enough. You have no SSA form at your hands (actually SSA names can appear and there'll be use->def links but no immediate uses). OK, back to the IPA route and your example in comment#2 - no, we currently do not have IPA dead store elimination or, if you'd view it in a very speci= al sense, IPA SRA does not consider instantiating 'var' in 'f' instead of pass= ing it down by reference (not sure if that's an optimization that would be generally useful - though I remember myself passing down dummy and unused out-paramet= ers to functions in GCC). Note that once you go the IPA route it becomes critical to do IPA pointer analysis which frankly GCC does not really have in a form I'd be comfortable enabling by default. IPA points-to does compute __attribute__((noinline)) f (int * var) { # PT =3D { D.1935 } (nonlocal) # ALIGN =3D 4, MISALIGN =3D 0 int * var_2(D) =3D var; [local count: 1073741824]: *var_2(D) =3D 1; return; } main () { int var; [local count: 1073741824]: # CLB =3D { D.1935 } f (&var); var =3D{v} {CLOBBER}; return 0; } so we know that f clobbers var but in f we do not know nothing in callers use it (so it is considered "nonlocal" aka global memory for following local optimizations). Maybe the pending IPA mod/ref analysis can solve this though I heard it's a TBAA mod/ref analysis and not a classical one.=