<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thanks for your replies. That was a very useful discussion.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Orthogonal to this change, the interesting topics brought up are improved diagnostics, and the cases the vectoriser misses. <span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">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.</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Cheers,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Sjoerd.</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> on behalf of Finkel, Hal J. via llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Sent:</b> 03 October 2019 00:18<br>
<b>To:</b> Michael Kruse <llvmdev@meinersbur.de><br>
<b>Cc:</b> llvm-dev@lists.llvm.org <llvm-dev@lists.llvm.org>; Kruse, Michael <michael.kruse@anl.gov>; hans@hanshq.net <hans@hanshq.net><br>
<b>Subject:</b> Re: [llvm-dev] vectorize.enable</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">On 10/2/19 5:31 PM, Michael Kruse wrote:<br>
> Am Mi., 2. Okt. 2019 um 15:56 Uhr schrieb Finkel, Hal J. <hfinkel@anl.gov>:<br>
>>> It's done by the WarnMissedTransformation and just looks for<br>
>>> transformation metadata that is still in the IR after all passes that<br>
>>> should have transformed them have ran. That is, it does not know why<br>
>>> it is still there -- it could be because the LoopVectorize pass is not<br>
>>> even in the pipeline -- and we cannot be more specific in the message.<br>
>>> However, -Rpass-missed=loop-vectorize may give more information.<br>
>> As I recall, there is some trade-off here because it's hard for a<br>
>> transformation to know that it's last - either the last run of that<br>
>> particular transformation in the pipeline or the last transformation in<br>
>> the pipeline that can service a particular transformation request (and<br>
>> this is especially true if there are multiple, separated pipelines<br>
>> involved, such as in LTO). This is why we did not have transformations<br>
>> warn if they can't perform the requested transformation for structural<br>
>> reasons - maybe they will be able to later. However, we also should<br>
>> improve the diagnostics in these cases.<br>
> This was not the only consideration. With ordered transformations,<br>
> such as vectorize after unroll-and-jam, the LoopVectorize does not<br>
> even have a chance to analyze the code since it is located after the<br>
> LoopUnrollAndJam pass. We would still warn that vectorization has not<br>
> been performed.<br>
><br>
><br>
>> I recommend that we consider taking a kind of delayed-diagnostic<br>
>> approach. When a pass cannot perform the requested transformation, it<br>
>> records some rationale into the metadata. That rationale can be reported<br>
>> by WarnMissedTransformation, if available, to make the diagnostic more<br>
>> helpful. If the transformation is later actually performed, then the<br>
>> extra information is discarded along with the transformation metadata<br>
>> itself.<br>
> I like the idea, but I am not sure how helpful are messages such as<br>
> "The exiting block is not the loop latch" or "Cannot identify array<br>
> bounds" are to the end user. It would still be an improvement.<br>
<br>
<br>
It probably wouldn't be, but might encourage some more-useful bug reports.<br>
<br>
<br>
><br>
> If there is no diagnostic metadata, do we keep emitting the current<br>
> message?<br>
<br>
<br>
That was my thought. If we don't know anything else, just keep doing <br>
what we're doing.<br>
<br>
<br>
> If there already is an explanation metadata, does the new one<br>
> override the old one or is it appended?<br>
<br>
<br>
Lacking data, I'll say append (because why throw away information?), but <br>
only print the last one by default (because, for example, if a pass runs <br>
multiple times, what I probably care about it why it couldn't perform <br>
the transformation during the last run, not the previous times when the <br>
IR might have been in a less-optimizable state) - that's probably less <br>
confusing.<br>
<br>
<br>
><br>
> We could also just a hint to the diagnostic such as<br>
> "-Rpass=loop-vectorize may provide more information".<br>
<br>
<br>
Agreed. That is probably the easiest thing, and might be the most useful <br>
as well. We just need a bit in the metadata to provide some information <br>
on whether the transformation was attempted but failed.<br>
<br>
-Hal<br>
<br>
<br>
><br>
> Michael<br>
<br>
-- <br>
Hal Finkel<br>
Lead, Compiler Technology and Programming Languages<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
llvm-dev@lists.llvm.org<br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div>
</span></font></div>
</body>
</html>