Page MenuHomePhabricator

[SVE][CodeGen] Legalisation of masked loads and stores

Authored by kmclaughlin on Jul 3 2020, 10:05 AM.



This patch modifies IncrementMemoryAddress to use a vscale
when calculating the new address if the data type is scalable.

Also adds tablegen patterns which match an extract_subvector
of a legal predicate type with zip1/zip2 instructions

Diff Detail

Event Timeline

kmclaughlin created this revision.Jul 3 2020, 10:05 AM

The patch overall looks good to me - just a question about the assert!


Do we know if this is something we catch earlier and hence should never get here? I just wonder if here it's not really an assert that something went wrong with the code, but perhaps we just hit a case we don't support yet? If it's just because we don't support it yet, instead of asserting we could do:

if (DataVT.isScalableVector())

report_fatal_error("Cannot currently handle compressed memory with scalable vectors");
sdesmalen added inline comments.Tue, Jul 7, 1:59 AM

Given that the type of VScale will be AddrVT, it's clearer to use AddrVT.getSizeInBits().getFixedSize(), that avoids the types being different.


Should this be using DataVT.getStoreSize() instead of DataVT.getSizeInBits() ?

Changes to IncrementMemoryAddress:

  • Changed the assert added for scalable vectors to a report_fatal_error
  • Replaced Addr.getValueSizeInBits().getFixedSize() with AddrVT.getSizeInBits().getFixedSize()
  • Use DataVT.getStoreSize() instead of DataVT.getSizeInBits()
kmclaughlin marked 3 inline comments as done.Tue, Jul 7, 11:10 AM
kmclaughlin added inline comments.

I think this is something that we just don't support yet, so I've changed this to report_fatal_error as suggested

efriedma added inline comments.Tue, Jul 7, 11:53 AM

This is part of the support for llvm.masked.expandload/llvm.masked.compressstore. There isn't a native instruction for that in SVE, but it's still a reasonable operation with scalable vectors.


Do we need to support extracting, for example, an nxv2i1 from an nxv16i1?

This revision is now accepted and ready to land.Fri, Jul 10, 12:25 AM
kmclaughlin added inline comments.Fri, Jul 10, 9:42 AM

We may need to support extracting a nxv2i1 from an nxv16i1, etc at some point, though I don't believe there are any code paths which would require this just now? At least, for the purposes of this patch I think we just need those patterns where the index is either 0 or half the number of elements.

efriedma accepted this revision.Fri, Jul 10, 2:23 PM



We do have a DAGCombine for EXTRACT_SUBVECTOR of an EXTRACT_SUBVECTOR; it isn't triggering here for some reason? I guess that's okay.

Thanks for reviewing this patch, @efriedma & @david-arm


I think the reason that DAGCombine doesn't trigger here is because it checks to make sure that the operand of the extract has only one use, which isn't the case in this patch as the original predicate will have multiple uses.

This revision was automatically updated to reflect the committed changes.