tree 405479f6eb3bcf7d1841aa3926bc3d995d0f1b09
parent 1b177e95689e8e5a9102a379c532d6d625f75a4a
author Benjamin Maxwell <benjamin.maxwell@arm.com> 1698261314 +0100
committer GitHub <noreply@github.com> 1698261314 +0100
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJlOWlCCRBK7hj4Ov3rIwAAorwIAFzuoXqjqaD/vDbwiYQUO8od
 gdZLIRMTpkRKreZFb2Q1M+xkNSggAXkXpRPUiJMdsqf7+zpSLnUmsYP9rhI02CbU
 nynFgFvAkqRWUa8tDjOIaXMlOn7ZbP1DIp3o+pnREBCPmak3c+6vbtV2Z1HBbwMi
 N3doElrqAY9/rGIBXRGYDWj6uRyYeg3gouSr2GJepziUMQOqFmIOVNivPhmXW5H/
 EK8UHyn5FapRSdWS7I3/vAS5Alduqx1YImJS3GddhZogRA9GIa6tllma8XPn9WQ9
 8+s7SoY6MhzQ7luro0jcGr3aokw8HX/G15hz5I9NDxQozMfhxJkBlmIZ9p2J2Mg=
 =VpFC
 -----END PGP SIGNATURE-----
 

[CPU][SVE] Enforce > 1 pow2 sizes when materializing scalable matmul lowering_configs (#15276)

The backend struggles to legalize non-power-of-two scalable vector sizes
and in many cases aborts. So if we can avoid it, we should stick to
power-of-two sizes. Likewise, 1x scalable vectors (e.g. vector<[1]xty>)
are poorly supported, so we fallback to fixed vectorization in that
case.