http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272
--- Comment #22 from rguenther at suse dot de <rguenther at suse dot de> --- On 12/17/13 9:29 AM, amker.cheng at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272 > > bin.cheng <amker.cheng at gmail dot com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |amker.cheng at gmail dot com > > --- Comment #21 from bin.cheng <amker.cheng at gmail dot com> --- > Hi Richard, > I looked into PR50955 for which the mentioned commit causing this PR is > applied: > > Commit > 2012-02-06 Richard Guenther <rguent...@suse.de> > > PR tree-optimization/50955 > * tree-ssa-loop-ivopts.c (get_computation_cost_at): Artificially > raise cost of expressions that replace an address with an > expression based on a different pointer. > > I noticed that the offending non-linear use in PR50955 is actually from memory > reference. If I understand the issue correct, the whole alias issue is > introduced by rewriting iv use with one base_object through candidate with > another incompatible base_object, and it is related to memory reference. An > genuine non-linear iv use (the pointer never de-referenced, like in this PR) > won't have this issue. > > So I come up this idea to relax the condition: > > - if (address_p) > + if (address_p > + || (use->iv->base_object > + && cand->iv->base_object > + && POINTER_TYPE_P (TREE_TYPE (use->iv->base_object)) > + && POINTER_TYPE_P (TREE_TYPE (cand->iv->base_object)))) > { > /* Do not try to express address of an object with computation based > on address of a different object. This may cause problems in rtl > > to non-linear uses which truly occurred in memory reference, something like: > > - if (address_p) > + if (address_p > + || (use->in_mem_ref_p > + && use->iv->base_object > + && cand->iv->base_object > + && POINTER_TYPE_P (TREE_TYPE (use->iv->base_object)) > + && POINTER_TYPE_P (TREE_TYPE (cand->iv->base_object)))) > { > /* Do not try to express address of an object with computation based > on address of a different object. This may cause problems in rtl > > The flag in_mem_ref_p can be set for appropriate uses when finding interesting > address uses. > > With this change, this PR should be resolved while not violating PR50955. > > I am not very much into 50955, so how does this sound? I can send a patch for > review if the idea is in right direction. I'm not 100% sure. > BTW, I cannot reproduce 50955 with the reported revision of GCC. The store > isn't deleted by pass_cd_dce, though it is re-written just as the PR > reported. > So maybe I just misunderstood something. It's been too long to remember ;) The issue boils down to a bogus TMR_SYMBOL. Later passes may forward a !use->in_mem_ref into a mem-ref, exposing the issue as well. Richard. > Any words? > > Thanks, > bin >
