tree 6c309112c47a9900c3c44b39c17168ee5bd6ad2a
parent 9cf4f917d6f4e762c726265310dd46658a0655af
author bjacob <benoitjacob@google.com> 1685644357 -0400
committer GitHub <noreply@github.com> 1685644357 -0400
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJkeORFCRBK7hj4Ov3rIwAAehEIAHlSMudrcODXAbTDOAoa5J16
 U1PoJd6hQbQZZ7B/hulIuTQRqGvK82ZYA0DqLHzIPQPhxs7A0FPMKJxWf2TXJnVF
 O2Iu77umd7SWedu5lTPv2dDZfO2pLE+PLPIZHwIdmWRNdv0mWZss9lufwlBRRXi2
 fBNe+UuPcjFC+Yn0Ypufbev7Ec4/b20t2himZYP6MeoqrNVl8Uiu+Vl4qFqM8EGR
 xDPmBj+kNsyfj375Jze+pn1VCpfXjd4KzX/sNxYRUEJPO7+VvhgRtvUsL2PYvyTj
 FMBsxMOHOtMo2/D1v+/SJX5iFJSzN63QJFiALb0d6i3ogUNffeFuEbhb2sMRxIk=
 =dBuc
 -----END PGP SIGNATURE-----
 

Fixes and simplifications to CPU-data handling (#13881)

In DispatchABI.cpp:
* Was not checking if CPU feature bits in the schema applied to the
target architecture.
* Was not checking if CPU feature bits belonged to field 0 even though
the current code only handles that. Other fields are currently unused
but at least now we will get an assert failure if that changes.
* Was building a vector of bits, then creating one `LLVM::OrOp`for each
bit. Instead, why not OR those bits in C++ and create a single
`LLVM::OrOp` with the resulting OR-ed value?
* Was not checking that the first character of each feature string was a
`'+'` before dropping it.
* Was room for simplification in how the schema was used.

Additionally, folding into this PR a simplification to `iree-cpuinfo` (a
standalone tool to report the host CPU's features exactly as detected by
IREE). It was quadratic-time, as it unnecessarily called
`iree_cpu_lookup_data_by_key` for each feature.