On Fri, Jun 17, 2016 at 4:37 PM, Jeff Law <l...@redhat.com> wrote: > On 06/17/2016 08:48 AM, Bin.Cheng wrote: >>>> >>>> >>>>> + /* FORNOW: Currently alias checks are not inherited for epilogues. >>>>> + Don't try to vectorize epilogue because it will require >>>>> + additional alias checks. */ >>>> >>>> >>>> Are the alias checks here redundant with the ones done for the original >>>> loop? If so won't DOM eliminate them? >>> >>> >>> I revisited this part recently and thought it should actually be safe to >>> assume we have no aliasing in epilogue because we are dominated by alias >>> checks of the original loop. So I prepared a patch to remove this >>> restriction >>> and avoid alias checks generation for epilogues (so we compute aliases >>> checks >>> required but don't emit them). I didn't send this patch yet. >>> Do you think it is a valid assumption? >> >> I recently visited that part and agree it's valid, unless epilogue >> loop is vectorized in larger vector-units, but that would be unlikely >> to happen, right? BTW, does this patch start all over analyzing >> epilogue loop? As you said the alias checks will be computed. > > I think we're OK either way. If you emit the checks, DOM ought to eliminate > them as they'd be dominated by the earlier check. Unfortunately DOM probably can't. Especially constant offsets are folded deep in expressions and they could be different under smaller vector-units. Even it can, it will introduce long live range since check result will be combined with some others. Not sure if all checks can be avoided, alignment checks should be ok too?
Thanks, bin > > But I'm a fan of not generating dumb code for later passes to clean up, so I > think we should just avoid generating the additional checks if we can > reasonably do so in the vectorizer. > > I can't envision a scenario where we'd want a larger vector size in the > epilogue than the main loop. > > Jeff >
