Original code only used vector loads/stores for explicit vector arguments.
It could also do more loads/stores than necessary (e.g v5f32 would
touch 8 f32 values). Aggregate types were loaded one element at a time,
even the vectors contained within.
This change attempts to generalize (and simplify) parameter space
loads/stores so that vector loads/stores can be used more broadly.
Functionality of the patch has been verified by compiling thrust
test suite and manually checking the differences between PTX
generated by llvm with and without the patch.
General algorithm:
- ComputePTXValueVTs() flattens input/output argument into a flat list of scalars to load/store and returns their types and offsets.
- VectorizePTXValueVTs() uses that data to create vectorization plan which returns an array of flags marking boundaries of vectorized load/stores. Scalars are represented as 1-element vectors.
- Code that generates loads/stores implements a simple state machine that constructs a vector according to the plan.
All right, now that I understand this, it's doing something deceptively simple. Perhaps:
Perhaps "CanVectorizeAt" is not a great name. I think we want "Param" in the name. Maybe CanMergeParamLoadStoresStartingAt? Ideally we'd also pick a name that doesn't sound like this returns a boolean, but I don't have a suggestion.