https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90591
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org,
| |jamborm at gcc dot gnu.org
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think while relying on a robust IPA analysis and optimization framework
sounds appealing the problem is _much_ easier solved before OMP/OACC lowering
and I would strongly suggest to tackle the problem from that side if you want 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 special
sense, IPA SRA does not consider instantiating 'var' in 'f' instead of passing
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-parameters
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 = { D.1935 } (nonlocal)
# ALIGN = 4, MISALIGN = 0
int * var_2(D) = var;
<bb 2> [local count: 1073741824]:
*var_2(D) = 1;
return;
}
main ()
{
int var;
<bb 2> [local count: 1073741824]:
# CLB = { D.1935 }
f (&var);
var ={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.
