https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #44 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 > > Jeehoon Kang <jeehoon.kang at sf dot snu.ac.kr> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |jeehoon.kang at sf dot > snu.ac.kr > > --- 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. 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. 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). I also don't think doing the above would solve the cases of equality compares of pointes themselves. (hopefully undefined) 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 ;)
