[PATCH] D9822: Reducing the costs of cast instructions to enable more vectorization of smaller types in LoopVectorize
silviu.baranga at arm.com
silviu.baranga at arm.com
Fri Jul 10 10:12:24 PDT 2015
sbaranga added a comment.
In http://reviews.llvm.org/D9822#201852, @samparker wrote:
> Hi Silviu,
>
> So i've added some comments for clarification and also removed the sub operands from the chains for simplicity as I didn't notice any performance difference in the tests I was looking at. I've also added support for 64-bit > 32-bit operations and updated the test file to reflect this.
>
> cheers,
Thanks Sam!
Some further comments:
Subtraction is a very common operation, it would be much nicer to get it now. wrt performance numbers this would only show up in a benchmark if it would affect the hot loop _and_ the loop would end up being vectorized.
Looking at what bits we don't care about seems like the right approach to me. I think an easier way to reason about these is to have a bitmask for each value in the chain that we're looking at, indicating what bits we care about. Different operations would do different things on this bitmask, and we would compute the value of the bitmasks starting from the trunc operations.
For example:
b = add a, c means that a and c have the same bitmask as b
The same would be true for mul, left shift, all bitwise operators, and sub (since sub can be written with and add and a not).
b = shr a, 2, and b has a bitmask of 0b00011 ( where 1 means we care, 0 don't care) means a has a bitmask of 0b01111 (technically it would be 0b01100, but this is an approximation).
This can probably be done for most operators.
Also, if you have an operation that takes a constant and you know what bits you care about it should be perfectly legal to truncate the constant and get rid of some of the bits that you don't care about.
Technically, we could set the mask values on the truncate operations and iterate using a work list until all bitmasks have converged, but that is best left for future work.
What would be your opinion on this?
Cheers,
Silviu
http://reviews.llvm.org/D9822
More information about the llvm-commits
mailing list