https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #15 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 18 May 2021, amker at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 > > --- Comment #14 from bin cheng <amker at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #12) > > So in number_of_iterations_ne it looks like the step 's' is always constant > > which makes me wonder if we can somehow use ranger to tell multiple_of_p > > (type, c, s) > > or at least whether, if c is x * s, the multiplication could have > > overflowed? > > Yeah, I am looking if "multiple of" can be feasibly checked in niter analysis, > with help of some basic information from multiple_of_p. > > BTW, I am not following changes in "ranger", how should I used in analysis? or > similar to value range info? I'm not sure - let's see if the ranger folks have any good idea here. Btw, there's tree_ctz which looks more conservative and could be used for power-of-two 's'. split_constant_offset also recently got refactoring to avoid a plethora of overflow issues it ran into, so we can eventually improve multiple_of_p to be correct without pre-conditions. But I fear that for DECL_SIZE & friends where we "know" that multiplications by 8 to get from byte to bit size do not overflow we cannot be too conservative here. Maybe in the end we need to distinguish those with new MULT_NO_OVERFLOW, PLUS_NO_OVERFLOW, etc. When creating those expressions we should already be using size_{bin,un}op. The conversion handling of course still looks bogus to me even in this context.
