[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[rguenther at suse dot de]

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

--- Comment #48 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 16 Nov 2015, ch3root at openwall dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
> 
> --- Comment #47 from Alexander Cherepanov <ch3root at openwall dot com> ---
> On 2015-11-16 14:00, rguenther at suse dot de wrote:
> >> --- Comment #43 from Jeehoon Kang <jeehoon.kang at sf dot snu.ac.kr> ---
> >> - Performance degradation due to "casted pointers as escaped" is insignificant.
> >
> > I think this is not true.  For example with MatLab (might be sth else,
> > if I don't remember correctly) you are required to pass pointers to
> > arrays in two halves in double(!) values (I believe the only function
> > argument type they support).  GCC happily makes points-to analysis work
> > through those.
> 
> But this is invalid C. First, it breaks strict aliasing rules. Second, 
> the representations of these doubles are free to change at any time 
> given their values are kept intact (e.g. change one NaN to another). 
> That is, unrelated improvements in other optimizations in gcc will break 
> all of this in the future, right?

You misunderstood, they marshall a pointer 'T *p' like

  unsigned int high = ((uintptr_t)p) >> 32;
  unsigned int low = ((uintptr_t)p) & (1 << 32 - 1);
  foo ((double) high, (double) low);

and in foo then do

foo (double hdouble, double ldouble)
{ 
  unsigned int high = (unsigned int) hdouble;
  unsigned int low = (unsigned int) ldouble;
  T *p = (T *)(((uintptr_t)high << 32) | (uintptr_t)low);

the important part here is to recognize that frobbing in points-to
analysis so you still see what 'p' points to in foo.

> > I added the current handling of pointers vs. integers for a
> > missed-optimization bug that said a hand-written memcpy loop
> > didn't properly transfer points-to info (properly as in
> > optimially for optimization).  GCC can now do that ;)
> 
> Nice! Does gcc properly transfer effective type info too, over a 
> hand-written memcpy loop? Just curious.

No, GCC doesn't have any effective type analysis / propagation.  It
only has the traditional type-based disambiguations of accesses
using the access type.

> On 2015-11-16 15:51, rguenther at suse dot de wrote:
>  >> Thank you for giving me the information.  I don't know the GCC 
> internals, so I
>  >> would like to ask how much it would cost to introduce the syntax for 
> pointer
>  >> subtractions.  I hope it is not that huge, but I really don't have 
> any idea.
>  >
>  > It would be quite some (mechanical) work but otherwise not too difficult.
>  > There is the choice whether to embed the division implicitely here or
>  > not.
> 
> If you choose to fix it please fix pr45779 on the way (see pr67999 for a 
> context).