https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
--- Comment #22 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 26 Jan 2015, amker at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 > > --- Comment #20 from amker at gcc dot gnu.org --- > (In reply to Richard Biener from comment #18) > > It's probably not correct to simply transfer range info from *idx to > > iv->base. > > Instead SCEV analysis needs to track the range of CHREC_LEFT when it > > analyzes > > the SSA use-def chain. That's of course a much bigger change :/ > > > > The patch may still help in some cases - I suppose the original testcase is > > reduced from sth else? > > I see it's a tricky problem, and I have to admit that I don't understand it > very well yet. The question is, is relax of POINTER_PLUS_EXPR constraint the > right way fixing this? I do remember some other PRs (other than this one or > bug 52563) are caused by this constraint according to your comments. Well, it's not sure that relaxing POINTER_PLUS_EXPR will help in the end... > Of course, take range information into consideration is always an > improvement. > Actually I have another possible example in iv elimination. Curently GCC > simply rejects elimination of an iv use with a candidate if the cand is of > smaller type, but as long as we can prove value of iv use can be represented > by > the smaller candidate, elimination is actually safe. But seems to me, fixing > this issue with value information is like a side-effect? Might be - but it's a matter of fixing the observable regression ;)
