[llvm] r348944 - [Unroll/UnrollAndJam/Vectorizer/Distribute] Add followup loop attributes.

[Jordan Rupprecht via llvm-commits]

Yes, -Wno-pass-failed, although it'd be better if there were something to
suppress just this one pass. I'll file a bug.

On Thu, Dec 13, 2018 at 4:34 PM Michael Kruse <llvm at meinersbur.de> wrote:

> Am Do., 13. Dez. 2018 um 18:18 Uhr schrieb Jordan Rupprecht
> <rupprecht at google.com>:
> > Thanks for taking a look -- I don't see "Can't unroll" when I run it on
> the real test case I have, but I do see:
> > Loop Unroll: F[<method name>] Loop %for.body
> >   Loop Size = 16
> >   partially unrolling with count: 1
> > And it looks like a count of 1 gets treated similarly to disabling loop
> unrolling.
>
> Correct.
> If there is !{!"llvm.loop.unroll.count", i32 1} it should also not
> give a warning message.
> It could also have determined that unrolling by a factor of '1' is the
> most profitable, i.e. it considered unrolling unprofitable.
>
> > The bitcode is identical in this case as well. (Attaching a better
> creduced test case that demonstrates this).
> >
> > I guess I have a cleanup to do to remove a bunch of unnecessary pragmas!
> Is there a simple way to (temporarily) disable this warning? My naive
> attempt of -Wno-pass-failed=transform-warning doesn't seem to be accepted.
>
> Did you try -Wno-pass-failed ? It seems that it does not support
> taking an option. You could submit a bug report.
>
> Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20181213/93558392/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4849 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20181213/93558392/attachment.bin>