As suggested by Ayal in D59995, we can mark instructions with
loop invariant arguments as uniform. They will always produce
the same result.
Now that we can have more uniform instructions, there were some
assertions that needed relaxing a bit.
Also, there still seems to be an issue with constant folding in LV not
being able to simplify some uniform values compared to their replicated
equivalents. I still have to look into that, but I wanted to make sure
the overall approach aligns well.
The overall impact of the change is probably quite low, but at least in
the test-suite, there are around 4 benchmarks were we ended up
vectorizing a few more loops.
Currently we still miss some uniform instructions, that only have
uniform operands, but that can be addressed as follow-up.
There's a distinction between (1) the truly "uniform values" of Legal->isUniform(), and (2) those of Cost->isUniformAfterVectorization() that "become" uniform. In both cases generating the single scalar value of lane zero suffices; the values of all other lanes need not be generated, because (1) they are all equal to that of lane zero, or (2) they are all dead. I.e., DemandedLanes={0} in case (2).
Instructions of case (1) should have ideally been LICM'd out, except for conditional instructions that have side-effects. Case (2) is what this assert is trying to verify - a user requesting the value of some lane>0 contradicts the liveness assumption; feeding it with the value of lane 0 may be feeding it a different, wrong value.
Note that this change to getOrCreateScalarValue() *alone* "fixes" PR40816, but there the users requesting the values of lanes>0 are essentially dead. Would be good to devise a test involving a predicated uniform-after-vectorization instruction, that is essentially live.
Would be good to come up with a better name than UniformAfterVectorization, which looks up a set named "Uniforms". Suggestions?