[llvm-dev] vectorize.enable

[Finkel, Hal J. via llvm-dev]

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 
confusing.


>
> 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.

  -Hal


>
> Michael

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