https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94043
--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> --- On March 24, 2020 3:59:35 AM GMT+01:00, "linkw at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94043 > >--- Comment #10 from Kewen Lin <linkw at gcc dot gnu.org> --- >(In reply to Richard Biener from comment #9) >> OK, so it's indeed vectorizable_live_operation not paying attention >to >> loop-closed SSA form. >> >> What it should do before building the lane extract is create a _new_ >> loop-closed PHI node for the vectorized def (vec_lhs), and then >> demote the loop-closed PHI node for the scalar def (lhs) which should >> _always_ exist to a copy. So from >> >> >> loop; >> >> # lhs' = PHI <lhs> >> >> >> go to >> >> loop; >> >> # vec_lhs' = PHI <vec_lhs> >> new_tree = BIT_FIELD_REF <vec_lhs', ...>; >> lhs' = new_tree; >> >> I think you can assert that the block of the loop-closed PHI >> (single_exit()->dest) always has a single predecessor, otherwise >> things will be more complicated. >> >> Can you try rework the code in this way? If that's too much just >tell >> me and I'll take care of this. > >Thanks Richi, I'll give it a shot! >I'd like to ensure my understanding: with the proposed fix, we ensure >the >single_exit()->dest should be the correct BB to be inserted, no chance >like >gimple_find_edge_insert_loc to get one new BB to be inserted, is it >right? Yes.
