[PATCH] support llvm.vectorization.vector_width metadata

[Tobias Grosser]

Hi,

I also have one comment.

On 05/27/2013 12:42 PM, Redmond, Paul wrote:
> +
> +'``llvm.vectorizer.width``' Metadata
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +This metadata instructs the loop vectorizer to vectorize the specified
> +loop using a SIMD width of ``N``.
> +
> +The first operand is the string ``llvm.vectorizer.width`` and the second
> +operand is an integer specifying the width. For example:
> +
> +.. code-block:: llvm
>

I am not fully sure about the exact meaning of this.

Does this MD say anything about legality or is it supposed to only 
overwrite the cost heuristics of the vectorizer?

For now it seems to me that this is just about the cost function and the 
way to vectorize. To proof that vectorization is legal, it seems it is 
still necessary that all the mem.parallel_loop_access metadata is 
available, which according to the current specification is enough to 
ensure vectorization is legal. Is this right?

Regarding this I have now two comments:

1) What happens with non-parallel, but vectorizable loops

When vectorizing by a width of 4, it is not necessary that the full loop 
is parallel, but rather that all dependences carried by this loop have a 
dependence distance > 4. Do you have any plans to model this in the 
meta-data?

2) Vectorization only legal if statements are executed in lock-step

For some loops, vectorization is legal if the statements are executed in 
lock step, but a thread parallel execution of the very same loop
is not legal. Do you have any plans to model this in your metadata?

I am not saying all this should be implemented in this patch, but it 
would be good to document if or if not this is implied.

And a last question to help my understanding:

Why is the vectorizer unrolling a loop and not the loop unroller? Or 
better, what is the reason this is implemented in the vectorizer?

Thanks,
Tobias


Tobias