[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] 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

[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

[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 #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

[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