[Bug c/43827] Intrinsic possibility: does not alias global data

[Bug c/43827] Intrinsic possibility: does not alias global data

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43827

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
                 CC|                            |mpolacek at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #7 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Preprocessed source missing for several years, closing.

[Bug c/43827] New: Intrinsic possibility: does not alias global data

[darkshikari at gmail dot com]

Take this code snippet from x264:

h->mc.mc_luma( pix   , 64, m->p_fref, m->i_stride[0], omx, omy-1, bw, bh,
&m->weight[0] );
h->mc.mc_luma( pix+16, 64, m->p_fref, m->i_stride[0], omx, omy+1, bw, bh,
&m->weight[0] );
h->mc.mc_luma( pix+32, 64, m->p_fref, m->i_stride[0], omx-1, omy, bw, bh,
&m->weight[0] );
h->mc.mc_luma( pix+48, 64, m->p_fref, m->i_stride[0], omx+1, omy, bw, bh,
&m->weight[0] );

After each call to mc_luma, gcc reloads h->mc.mc_luma,  m->p_fref, and
m->i_stride[0] even if restrict is used.  It does this because it cannot prove
at compile-time that none of these are pointers to some global data which
mc_luma might modify.  Being that mc_luma is a function pointer, even link-time
optimization may have trouble proving this sort of thing.  Obviously we could
create local variables for all of these values, but when trying to optimize
huge amounts of code, this quickly becomes ugly and messy.

A solution for this problem might be an intrinsic to tell gcc that a particular
pointer never aliases global/static data and thus can be assumed to be
unchanged across function calls--and thus does not need to be reloaded.

Another, similar solution might be an intrinsic that says that a given function
never modifies global state.  This could be applied to a function pointer as
well as a function.  That would instead offload the task to the individual
function instead of the individual pointer.

Alexander Strange suggested that some of this might be possible in 4.6 given
the IPA-PTA optimization framework, so I'm curious whether these ideas are
feasible or not.


-- 
           Summary: Intrinsic possibility: does not alias global data
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: darkshikari at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43827

[Bug c/43827] Intrinsic possibility: does not alias global data

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2010-04-21 09:29 -------
They are feasible, but they do need a very strict specification to be usable.
With 4.6 you can check the -alias dumps when building with -flto -fipa-pta
to see if the compiler maybe can already analyze the situation correctly.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43827

[Bug c/43827] Intrinsic possibility: does not alias global data

[darkshikari at gmail dot com]

------- Comment #2 from darkshikari at gmail dot com  2010-04-21 22:07 -------
Here's what the compiler currently says about one of these calls using "-flto
-fipa-pta -fwhole-program -fdump-tree-optimized-alias -O3 -fomit-frame-pointer
-ffastmath":

# PT = nonlocal unit-escaped
D.9637_762 = h_79(D)->mc.mc_luma;
# PT = nonlocal unit-escaped
D.9343_763 = m_61(D)->weight;
bmy_764 = bmy_20 + 1;
D.9344_765 = m_61(D)->i_stride[0];
# USE = anything
# CLB = anything
D.9637_762 (&pix[16], 64, D.9345_761, D.9344_765, bmx_5, bmy_764, bw_63, bh_65,
D.9343_763);

After the linking step, using LTO:

# PT = anything
D.54843_762 = h_79(D)->mc.mc_luma;
# PT = anything
D.55040_763 = m_61(D)->weight;
bmy_764 = bmy_20 + 1;
D.55039_765 = m_61(D)->i_stride[0];
# USE = anything
# CLB = anything
D.54843_762 (&pix[16], 64, D.55038_761, D.55039_765, bmx_5, bmy_764, bw_63,
bh_65, D.55040_763);

If I'm reading this right, it doesn't seem it's able to infer anything
whatsoever about it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43827

[Bug c/43827] Intrinsic possibility: does not alias global data

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2010-04-21 22:09 -------
Can you provide the preprocessed source for your testcase?


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43827

[Bug c/43827] Intrinsic possibility: does not alias global data

[darkshikari at gmail dot com]

------- Comment #5 from darkshikari at gmail dot com  2010-04-21 22:24 -------
One somewhat unrelated issue I had when attempting to compile using LTO: we
have about 5 arrays in C that are referenced from YASM-syntax assembly code. 
Even I add __attribute__((used)), LTO/wholeprogram seems to optimize these out
in the link-time optimization step.  This results in the link failing when it
comes time to link the .o files for the assembly functions.

It seems conceptually wrong that it should be impossible to reference C arrays
from asm code when using LTO + wholeprogram.  Is there any way around this
beyond copy-pasting all this data, is this a bug, or is this intended behavior?


-- 

darkshikari at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|tree-optimization           |c


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43827

[Bug c/43827] Intrinsic possibility: does not alias global data

[darkshikari at gmail dot com]

------- Comment #6 from darkshikari at gmail dot com  2010-04-22 06:31 -------
It seems that __attribute__((pure)) can already do this for many instances of
this situation--but it doesn't work for function pointers.

Is this an arbitrary limitation, or would serious work be necessary to make
((pure)) work for function pointers?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43827