https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #36 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 26 May 2015, gil.hur at sf dot snu.ac.kr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 > > --- Comment #35 from Chung-Kil Hur <gil.hur at sf dot snu.ac.kr> --- > (In reply to rguent...@suse.de from comment #34) > > On Sat, 23 May 2015, gil.hur at sf dot snu.ac.kr wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 > > > > > > --- Comment #33 from Chung-Kil Hur <gil.hur at sf dot snu.ac.kr> --- > > > Dear Richard, > > > > > > Thanks for the detailed response. > > > > > > I have a suggestion for a solution of the problem, which is based on my > > > paper > > > to appear at PLDI 2015. > > > > > > * A Formal C Memory Model Supporting Integer-Pointer Casts. > > > Jeehoon Kang, Chung-Kil Hur, William Mansky, Dmitri Garbuzov, Steve > > > Zdancewic, Viktor Vafeiadis. > > > http://sf.snu.ac.kr/gil.hur/publications/intptrcast.pdf > > > > > > The suggestion is simple. > > > You do not need to turn off the phiopt optimizations. > > > We propose to slightly change the following assumption. > > > > > > > PTA considers that all pointers coming from integer constants > > > > point to global memory only. > > > > > > Here, if you change this as follows, you can solve the problem. > > > > > > * All pointers coming from integer constants can point to only global > > > memory > > > and > > > local variables whose addresses have been cast to integers. > > > > Ok, so you basically add a 2nd class of "escaping". So in GCC PTA > > terms you'd add a new ESCAPE-like 'INTEGER' variable with > > > > INTEGER = NONLOCAL > > > > and add > > > > INTEGER = x > > > > constraints for each > > > > .. = (integer-type) &x > > > > conversion and for the reverse > > > > ptr = (pointer-type) i > > > > add > > > > ptr = INTEGER > > > > > Also, we expect that this would not decrease the optimization performance > > > of > > > GCC very much because those variables whose addresses have been cast to > > > integers tend to be escaped (e.g. passed to a hash function, or stored in > > > the > > > memory). > > > > Well - the above basically makes _all_ pointers converted from integers > > point to non-local memory, it also basically globs all pointers > > converted from integers into a single equivalence class. > > Yes, this is right. > > > So I think you underestimate the effect on optimization (but I may > > overestimate the effect on optimization of not simply making all > > pointers converted from integers point to all globals and all > > address-taken locals, aka ANYTHING in GCC PTA terms) > > Just one minor correction: > all address-taken locals -> all address-taken-and-cast-to-integer locals > > Yes, I agree. > In order to understand the effect, we need some empirical evidence. > I am interested in this direction. > So, I wonder what benchmarks you usually use to check the effect of compiler > optimizations. > More specifically, are SPEC benchmarks enough? or do you use some other > benchmarks too? SPEC CPU tends to capture most of this though we also periodically check other "benchmarks" such as firefox and its few performance tests or similar big C++ programs.
