[PATCH] Add a Scalarize pass

[Richard Sandiford]

Michael Ilseman <milseman at apple.com> writes:
>> It also felt more natural to handle insertelement like this rather than
>> create a scattered form for every insertelement instruction.
>> 
>> I agree that using a reverse post-order traversal would cut down
>> on the number of cases in which we create a sequence of extractelements
>> for an instruction only for us later to scalarise the instruction itself.
>> I'm just not sure whether the overhead of creating the traversal
>> order would outweight the benefits there or not.  One thing in favour
>> of the current approach is that it should be cheaper for functions that
>> don't have vector operations.
>> 
>
> The overhead would be that up-front we traverse the CFG and make a
> set+stack of BBs, keeping the stack around for the duration of
> runOnFunction. I suppose it may depend largely on what constitutes your
> functions. This is a specialized pass for a specialized domain, so I
> would normally assume that domain has a fair number of vectors. So,
> maybe an RPOT would be cheaper than potentially generating lots of extra
> IR. However, it might be worse on code with few scalarizable vectors and
> tons of small BBs. As you mentioned earlier about lazy vs. eager,
> avoiding creating spurious IR is worth a little bit of analysis.
>
> I might of missed this earlier in the thread, but what is your specific domain?

Well, the original motivation was llvmpipe, but as I mentioned in
the other thread, I wanted the pass to be as general as the associated
codegen type legalisation.  I can't see any situation in which scalarising
arithmetic and shuffling at the IR level would produce worse results
than scalarising it in SelectionDAG.  So I'd like to see this used for
C and C++ compilation too (or in general anything that could have
vectors from the outset).

For llvmpipe there's no real benefit for using reverse post-order,
since the IR examples I've looked at so far are already in the order
we want.

Thanks,
Richard