-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
indvars pass creates dangling pointers in SCEV handles #1859
Comments
I'm not able to produce this crash on ppc32-darwin. |
I can reproduce this on x86 linux. It's crashing in ETForest called from the ==30124== Invalid read of size 2
So IndVarSimplify.cpp:402 deleted a Value that ScalarEvolution.cpp:373 is trying |
reduced by hand My previous explanation of the valgrind reading were correct but not as Here's the indvars debug output: INDVARS: RLEV: AfterLoopVal = %tmp. = add i32 %stream_ptr.142038.us.ph.ph1, *** The problematic delete: %stream_ptr.132032.us.lcssa being replaced with INDVARS: Deleting: %stream_ptr.132032.us = add i32 %pixel_x.232031.us, INDVARS: Rewrote IV '{ 0,+, 1}<bb1326.us>' %pixel_x.232031.us = phi i32 [ INDVARS: Deleting: phi i32 [ %tmp1341.us, %bb1326.us ], [ 0, and then valgrind kicks in. I tried fixing it with SE->deleteInstructionFromRecords(PN) right before PN is |
cc'ing Owen because this may be related to his LCSSA work. Owen, feel free to |
I can't reproduce on darwin-x86 either. |
lauro or nick, can you please try this patch? If it works (i.e. no crash and valgrind clean) let me know Thanks, -Chris RCS file: /var/cvs/llvm/llvm/lib/Transforms/Scalar/IndVarSimplify.cpp,v
|
I can't produce the crash with the "reduced by hand" testcase. Chris, the patch doesn't solve the problem. |
Here is another related chunk: --- IndVarSimplify.cpp 6 May 2007 13:37:16 -0000 1.119
Nick, please see if these fix the valgrind output. It is entirely possible that nick and lauro are hitting different issues here. Lauro, does the second fix it -Chris |
I had already written the same as Lauro's patch and found that it didn't work. |
With both patches applied, I get the same valgrind errors. |
ok, well they should work. Perhaps SCEV isn't properly releasing all memory? I don't really know, and I |
The SCEVHandle for %tmp1339.us is "(%pixel_x.232031.us + undef)", except that How is a SCEVHandle supposed to be informed that an RAUW occured? |
scevhandles can't be automatically updated. The client (e.g. indvars) needs to know to let go of these. If this is internal to SCEV (i.e. it the value in the value map, then the existing calls should do it). -Chris |
I don't think the existing calls will do it. getSCEV(%x) is called which caches the expression (%y + %z) in Scalars. Is there supposed to be some mechanism to deal with this? The SCEV for %y |
patch fixes problem This patch changes deleteInstructionFromRecords to iterate through the uses and For bonus points when reviewing, prove that the while loop always terminates. |
Fixed. Patches here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070604/050264.html Testcase here: Transforms/IndVarsSimplify/2007-06-06-DeleteDanglesPtr.ll |
…oncallableinfo_defensive_check [LLDB] Add a defensive check for member__f_
Extended Description
laurov@laurov-desktop:~$ opt bugpoint-reduced-simplified.bc -indvars -o tmp.bc
opt((anonymous namespace)::PrintStackTrace()+0x1a)[0x86674fe]
opt((anonymous namespace)::SignalHandler(int)+0x112)[0x86677c4]
[0xffffe420]
opt(llvm::ETNode::DominatedBySlow(llvm::ETNode*)+0x18)[0x8419a4e]
opt(llvm::ETForestBase::dominates(llvm::BasicBlock*,
llvm::BasicBlock*)+0xba)[0x8419b0e]
opt[0x8629c2d]
opt[0x862a715]
opt(llvm::InstVisitor<(anonymous namespace)::Verifier,
void>::visitAdd(llvm::BinaryOperator&)+0x18)[0x862eea8]
opt(llvm::InstVisitor<(anonymous namespace)::Verifier,
void>::visit(llvm::Instruction&)+0xe6)[0x862f6d0]
opt(void llvm::InstVisitor<(anonymous namespace)::Verifier,
void>::visit<llvm::ilist_iteratorllvm::Instruction
The text was updated successfully, but these errors were encountered: