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).
