[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 #46 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 16 Nov 2015, jeehoon.kang at sf dot snu.ac.kr wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
> 
> --- Comment #45 from Jeehoon Kang <jeehoon.kang at sf dot snu.ac.kr> ---
> > 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.
> 
> Thank you for giving me an example.  Yet, I think it is a little bit
> unfortunate for MatLab (or sth else) to pass pointers by packing two into a
> double, at least due to the readability problem.  I think it is beyond the
> intended usage of the C/C++ language, but I understand that GCC is the
> time-honored compiler for various software and systems.
> 
> 
> 
> > The other (unfortunate) thing is that in GCC pointer subtraction
> > is always performed on integers, thus for the C source code
> > 
> >  int idx = ptr1 - ptr2;
> > 
> > we internally have sth like
> > 
> >  int idx = ((long)ptr1 - (long)ptr2) / 4;
> > 
> > so you can't really treat pointers as "escaped" here without loss.
> 
> 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.

> > Note that we've had this (kind of) in the past and it tried to go
> > without making pointers escaped at these points but only consider
> > casts from integers to pointers as pointing to anything.  But
> > that's wrong correctness wise (not then treating the cast to integer
> > as escape point).
> 
> Treating the cast to integer as escape point is proven-correct by a
> machine-checked proof (in Coq) for various standard optimization examples, such
> as CP, DCE, dead allocation elimination, etc.  For more detail, please see the
> paper above-mentioned.

Yes, I agree that making this an escape point is enough.