[llvm-dev] vectorize.enable

Fri Oct 4 07:28:21 PDT 2019

Thanks for your replies. That was a very useful discussion.
I won't recommit on a Friday afternoon, but will do on Monday, as it looks like we agreed again on the direction and the change.
Orthogonal to this change, the interesting topics brought up are improved diagnostics, and the cases the vectoriser misses. I will briefly look why this particular case isn't vectorised, but I suspect that it's a simple case of some prep / clean-up passes not running at Oz.

Cheers,
Sjoerd.
________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Finkel, Hal J. via llvm-dev <llvm-dev at lists.llvm.org>
Sent: 03 October 2019 00:18
To: Michael Kruse <llvmdev at meinersbur.de>
Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>; Kruse, Michael <michael.kruse at anl.gov>; hans at hanshq.net <hans at hanshq.net>
Subject: Re: [llvm-dev] vectorize.enable

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

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191004/43fb82c6/attachment-0001.html>