https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69728
--- Comment #20 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 19 Sep 2017, spop at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69728 > > --- Comment #19 from Sebastian Pop <spop at gcc dot gnu.org> --- > > So how'd we properly handle a valid empty domain? > > DCE the statement. > > If the domain for a statement is empty, it means that the statement does not > execute: it is dead code. > > I think we are better enforcing the elimination of the statement as this wrong > analysis (or translation) of the number of iterations could produce wrong > code. That was my thinking, I put it on my TODO to figure out how to "DCE" a stmt (or in this case it's rather the whole "loop body", right?). I've not fully found my way through initial schedule building yet (otherwise I would have tried refactoring to not operate in pbb vector order but more naturally follow the SESE in a CFG walk with maintaining a BB -> pbb mapping). > > I assume P_21 is c.7_12 > > the number after P_ is the ssa variable number, so P_21 is c.7_21. > > > we have 0 <= i1 <= 2147483637, whereever that comes from. > > you can think about i1 as a canonical induction variable: 0 <= i1 > and i1 is indexing all iterations in that loop: i.e., i1 is incremented by 1. > > > Probably from the i1 <= 2147483637 constraint > > this constraint is added based on the type of the induction variable that > gives > an upper bound for the iteration domain. > > > 4294967296*floor((-1 - P_21)/4294967296) < -P_21 - i1 > > Yes, this constraint seems to be wrong. It indeed looks like so though I wasn't able to nail down what goes wrong. Unfortunately the extract_affine fixes didn't affect this one in a positive way.
