Are there any LLVM guidelines / documentation for handling larger-than-legal
data types (either scalars or vectors)?
Currently, the backend may crash , miscompile , or make a big mess 
when presented with data types that are bigger than native.
I think scalars and vectors shouldn't be lumped together here.
IMHO, the only rule should be "it's all legal".
In practice, larger-than-legal vectors shouldn't pose a problem.
(much) Larger-than-legal integers however, aren't well supported. As
Duncan says in , it's just that no one implemented the arbitrary
But you're right, if saying we support any size is a lie, maybe we
should reconsider. I'll leave that part to others though.
In the case of , is it a bug in the vectorizer to produce a non-legal
vector type (<16 x i64>) or should the backend be able to handle that more
reasonably? In that particular case, things are further complicated because
-loop-unroll is able to completely remove the loop and the large vector type
Like Quentin says, this looks like a bug in the cost model.
From what I've seen, the loop vectorizer cost model looks at
load/store/PHI when selecting the vectorization factor (cf.
Later, when computing the cost for each possible factor,
BasicTTI::getCmpSelInstrCost decides that an icmp <16 x i64> costs 8,
because it only counts the number of splits.
I'm not clear about the solution in this case. I'm guessing
getWidestType ignores other instructions justifiably on purpose.
Maybe the legalization cost scaling in BasicTTI should be superlinear?
i.e., (cost of 4 splits) > 2 * (cost of 2 splits)
As a quick experiment, changing getCmpSelInstrCost to square the
TypeLegalizationCost produces a better-looking <4 x i64>.