[llvm-dev] vectorize.enable

Finkel, Hal J. via llvm-dev llvm-dev at lists.llvm.org
Wed Oct 2 16:18:31 PDT 2019

On 10/2/19 5:31 PM, Michael Kruse wrote:
> Am Mi., 2. Okt. 2019 um 15:56 Uhr schrieb Finkel, Hal J. <hfinkel at anl.gov>:
>>> It's done by the WarnMissedTransformation and just looks for
>>> transformation metadata that is still in the IR after all passes that
>>> should have transformed them have ran. That is, it does not know why
>>> it is still there -- it could be because the LoopVectorize pass is not
>>> even in the pipeline -- and we cannot be more specific in the message.
>>> However, -Rpass-missed=loop-vectorize may give more information.
>> As I recall, there is some trade-off here because it's hard for a
>> transformation to know that it's last - either the last run of that
>> particular transformation in the pipeline or the last transformation in
>> the pipeline that can service a particular transformation request (and
>> this is especially true if there are multiple, separated pipelines
>> involved, such as in LTO). This is why we did not have transformations
>> warn if they can't perform the requested transformation for structural
>> reasons - maybe they will be able to later. However, we also should
>> improve the diagnostics in these cases.
> This was not the only consideration. With ordered transformations,
> such as vectorize after unroll-and-jam, the LoopVectorize does not
> even have a chance to analyze the code since it is located after the
> LoopUnrollAndJam pass. We would still warn that vectorization has not
> been performed.
>> I recommend that we consider taking a kind of delayed-diagnostic
>> approach. When a pass cannot perform the requested transformation, it
>> records some rationale into the metadata. That rationale can be reported
>> by WarnMissedTransformation, if available, to make the diagnostic more
>> helpful. If the transformation is later actually performed, then the
>> extra information is discarded along with the transformation metadata
>> itself.
> I like the idea, but I am not sure how helpful are messages such as
> "The exiting block is not the loop latch" or "Cannot identify array
> bounds" are to the end user. It would still be an improvement.

It probably wouldn't be, but might encourage some more-useful bug reports.

> If there is no diagnostic metadata, do we keep emitting the current
> message?

That was my thought. If we don't know anything else, just keep doing 
what we're doing.

>   If there already is an explanation metadata, does the new one
> override the old one or is it appended?

Lacking data, I'll say append (because why throw away information?), but 
only print the last one by default (because, for example, if a pass runs 
multiple times, what I probably care about it why it couldn't perform 
the transformation during the last run, not the previous times when the 
IR might have been in a less-optimizable state) - that's probably less 

> We could also just a hint to the diagnostic such as
> "-Rpass=loop-vectorize may provide more information".

Agreed. That is probably the easiest thing, and might be the most useful 
as well. We just need a bit in the metadata to provide some information 
on whether the transformation was attempted but failed.


> Michael

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

More information about the llvm-dev mailing list