Discussion was had that there are a number of SROA issues that result
from generating these types, and OpenCL actually prohibits these types
as well. We'll likely need to find someone to implement Boolean
differently(Alexey Voronov?), but I hope we can use test results from
this review to figure out what needs removing.

After a little bit of investigation I think I recall why we added support for boolean type for extended vector type attribute.
Operands of relation SPIR-V instructions are vector of bools and SPIR-V translator tools converts only <n x i1> type to vector of bools.

SPIR-V translator does the conversion from OpenCL built-ins (with vector of integers parameters) to SPIR-V built-ins (with vector of bools parameters) at LLVM IR canonization pass.
https://github.com/KhronosGroup/SPIRV-LLVM-Translator/blob/master/lib/SPIRV/OCL20ToSPIRV.cpp#L660

Maybe we could add some patch fixing parameter types to the translator.

+@Naghasan any thoughts on that?

Glad you ping me on that, I was hitting some issues related to this for bindings.

I don't think it is a good solution to allow vector of bool. To be stored in memory, the bool type needs to be coerced into at least a byte which causes a problem for vector as it assumes a memory layout.

Maybe we could add some patch fixing parameter types to the translator.

Maybe the rational/realistic position for the translator would be to expect i8 for builtin parameters that uses bool (as a canonical representation) and do char <-> i1 conversion on the fly during the translation. It may be a pain to implement but not all languages have a bool type (e.g. C), so expecting a bool would exclude them here.

So I think this would make sense.

@Fznamznon, will upload another PR the proper fix for the regressed tests.