On Wed, Jan 27, 2016 at 3:18 AM, Bernd Schmidt <bschm...@redhat.com> wrote: >> +This option is disabled by default for most languages, enabled by >> +default for languages that use garbage collection. > > > This is not true as of this patch.
Yes. As I said elsewhere, my intent is to do that as a separate patch. >> Index: tree-ssa-loop-ivopts.c >> =================================================================== >> --- tree-ssa-loop-ivopts.c (revision 232580) >> +++ tree-ssa-loop-ivopts.c (working copy) >> @@ -2815,6 +2815,16 @@ >> struct iv_cand *cand = NULL; >> tree type, orig_type; >> >> + /* -fkeep-gc-roots-live 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_keep_gc_roots_live && POINTER_TYPE_P (TREE_TYPE (base))) >> + return NULL; > > > Is there a reason to exclude a candidate if the base is just a pointer to an > object? Or does it just not make a difference? Off hand I don't see how it would make a difference. If the pointer is not incremented or indexed, ivopts isn't going to be able to do anything with it anyhow. > I feel somewhat uneasy that this probably isn't a full solution either. But > it seems like a reasonable starting point. I'm still not sure we want to > advertise the option to users, as it might overpromise at the moment. Do we > have precedent for internal-only options? I suppose an option marked as "Undocumented" could be considered to be internal-only. The option does in principle over-promise. On the other hand, it's probably pretty good in practice; Java and Go have gotten by without this option for many years. I only have a single test case that shows a real problem, and it only shows up on PPC64. That said, I'm fine with making the option undocumented if you prefer. > Or maybe we do need some other form to represent the need to keep a pointer > alive in the IL. I suspect that for gcc-6 your patch is probably reasonable, > but we should mark the option as internal and likely to go away in the > future. Why would the option be likely to go away? The option name is chosen (based on Richi's suggestion) so that it can be applied to other passes besides ivopts, and it's useful for languages that do not normally do garbage collection. If we improve the implementation as you suggest, it would still be reasonable to keep the option. Ian
