[PATCH] D136251: [LoopVectorize] Use available masked vector functions when required
    David Sherwood via Phabricator via llvm-commits 
    llvm-commits at lists.llvm.org
       
    Fri Mar 24 07:01:36 PDT 2023
    
    
  
david-arm added inline comments.
================
Comment at: llvm/include/llvm/Analysis/VectorUtils.h:285
+    // otherwise we look for one that matches the supplied VF.
+    auto Mappings = VFDatabase::getMappings(CI);
+    for (VFInfo Info : Mappings)
----------------
huntergr wrote:
> david-arm wrote:
> > I wonder if it's useful to have a `VFDatabase::getMaskedMappings` variant or something like that? That way we can avoid walking through all the mappings if there aren't going to be any masked variants anyway. I was thinking about something like this:
> > 
> >   auto Mappings = VFDatabase::getMaskedMappings(CI);
> >   if (Mappings.emtpy())
> >     return false;
> >   for (VFInfo Info : Mappings)
> >     if (!VF || Info.Shape.VF == *VF)
> >       return true;
> >   return false;
> > 
> > Do you think it's worth it?
> getMaskedMappings would just end up iterating over all the variants anyway -- this code doesn't really do any caching, since it's a static method rather than an instance method. So every time we ask for variants we re-decode the mangled names to figure out which functions we should be looking at.
> 
> I think LoopVectorize and VectorUtils could be much smarter about this, but that's something for another patch.
Sure, I was just thinking we could avoid walking over the mappings twice like we're doing at the moment. With your patch as it stands we call `VFDatabase::getMappings`, which walks over all the mappings and creates a set of them, which we then iterate over yet again here. However, if you had a function such as `VFDatabase::getMaskedMappings` you can at least optimise for the (common) case where there are no masked variants, i.e.
```auto Mappings = VFDatabase::getMaskedMappings(CI);
if (Mappings.emtpy())
  return false;```
That only requires walking over the mappings once, and if there are masked mappings it also makes the second list walk shorter because you've already filtered out the non-masked variants.
Anyway, I wouldn't hold the patch up for this - I just thought it seemed like it might reduce computational effort.
CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136251/new/
https://reviews.llvm.org/D136251
    
    
More information about the llvm-commits
mailing list