On Wed, Jan 20, 2016 at 3:02 PM, Ian Lance Taylor <i...@golang.org> wrote: > On Wed, Jan 20, 2016 at 3:13 AM, Richard Biener > <richard.guent...@gmail.com> wrote: >> On Wed, Jan 20, 2016 at 6:48 AM, Ian Lance Taylor <i...@golang.org> wrote: >>> As discussed at https://gcc.gnu.org/ml/gcc/2016-01/msg00023.html , the >>> Go frontend needs some way to prevent ivopts from temporarily removing >>> all pointers into a memory block. This patch adds a new option >>> -fcollectible-pointers which makes that happen. This is not the best >>> way to solve the problem, but it seems safe for GCC 6. >>> >>> I made the option -fcollectible-pointers intending that any similar >>> optimizations (or, rather, non-optimizations) can be captured in the >>> same option. And if we develop a better approach for ivopts, it can >>> still be covered under this option name. >>> >>> Bootstrapped and tested on x86_64-pc-linux-gnu. OK for mainline? >> >> + // -fcollectible-pointers means that we have to keep a real pointer >> + // live, but the ivopts code may replace a real pointer with one >> + // pointing before or after the memory block that is then adjusted >> + // into the memory block during the loop. >> + // FIXME: It would likely be better to actually force the pointer >> + // live and still use ivopts; for example, it would be enough to >> + // write the pointer into memory and keep it there until after the >> + // loop. >> + if (flag_collectible_pointers && POINTER_TYPE_P (TREE_TYPE (base))) >> + return; >> >> please use C-style comments. > > Whoops, sorry, too much Go coding. > >> The above is to add_autoinc_candidates >> which I find weird - we certainly produce out-of-bound pointers even on >> x86 which isn't auto-inc. > > Despite the name, this is used on all systems. That is the function > where we consider using BASE + STEP * i in a loop. > >> So this can't be a complete fix. I guess you >> are correct in disabling some offsetted address IV candidates but >> I think there's some other issues regarding to exit test replacement >> maybe (replace ptr <= ptr2 with ptr != ptr2 or so). > > I'll look into that. > >> While the docs of the option look fine I find >> >> +fcollectible-pointers >> +Common Report Var(flag_collectible_pointers) Optimization >> +Ensure that pointers are always collectible by a garbage collector >> >> somewhat confusing (we don't collect pointers but pointed-to memory). >> Maybe "Ensure that derived pointers always point to the original object"? >> In that light -fcollectible-pointers is a bad option name as well. Maybe >> -fall-pointers-are-gc-roots or sth like that. > > I'm OK with that, or how about -fkeep-gc-roots-live?
Sounds good. Richard. > Ian
