Reverting [SCEV][IndVarSimplify] insert point should not be block front
Zheng CZ Chen via llvm-commits
llvm-commits at lists.llvm.org
Tue Jul 14 21:22:24 PDT 2020
Hi Serge,
Thanks for exposing this issue.
I am working on the fix.
Thanks.
BRS//
Chen Zheng
Power Compiler Backend Developer
From: Serge Guelton <sguelton at redhat.com>
To: Chen Zheng <czhengsz at cn.ibm.com>
Cc: llvm-commits at lists.llvm.org
Date: 2020/07/14 09:03 PM
Subject: [EXTERNAL] Reverting [SCEV][IndVarSimplify] insert point should
not be block front
Hi Chen Zheng,
I've reverted commit f1efb8bb4ba0584a9b994f3404a2c62920ce6652
[SCEV][IndVarSimplify] insert point should not be block front.
because it breaks validation (a recent expensive check that tests return
status
of LLVM passes).
The check fails because of these lines:
WidePhi = dyn_cast<PHINode>(Rewriter.expandCodeFor(AddRec, WideType,
InsertPt));
if (!WidePhi)
return nullptr;
Basically `Rewriter.expandCodeFor` generates new instructions but if the
`return
nullptr` path is taken, the caller considers nothing happens, and this may
end
up with the pass claiming no change while something actually happening.
I could have patched the caller to take the change into account, but it
seems it
hides a deeper issue: in the case of that early exit, no code should be
added,
or we should remove it.
Can you please update the patch to take that into account?
Thanks, and again sorry for reverting the patch. It seems to me it's better
to revert
this patch than reverting the check.
Best,
Serge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200715/d91ceeb7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200715/d91ceeb7/attachment.gif>
More information about the llvm-commits
mailing list