https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 12 Jul 2021, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419 > > --- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > (In reply to rguent...@suse.de from comment #16) > > Well, my point was to avoid pessimizing the VN done from cunrolli ;) > > Of course any duplication / threading can improve __bos precision, > > but then any transform also risks breaking it. Your example > > is IMHO too artificial as good argument. > > Is that VN so important for cunrolli itself (I mean, what harm will be there > if > it is only VN simplified during FRE after it)? Does it affect anything but > the > number of statements that perhaps is used to determine whether to unroll > completely or not? Sure, if you have address comparisons inside the loop body that resolve by unrolling (by making the index into an array part constant), then this changes the size estimate used for further unrolling outer loops. > My testcase was artificial, sure, but I was worrying about short loops (say 2 > iterations) doing some strcpy/memcpy etc. where having more precise object > size > would improve security. Well, we can always find examples where security is improved and we can find examples where optimization is pessimized. We can't unfortunately both have the cake and also eat it.
