<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 08/11/2018 02:02 PM, TB Schardl via
llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGAvDYgwaa9B-tvOHR2pyKLVWsm_CczJtt+Vy0gJqPxiY3ySjQ@mail.gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">Hey Hal and Michael,
<div><br>
</div>
<div>Thanks for the replies.</div>
<div><br>
</div>
<div>You're right, I was using the old pass manager. I already
wrote a separate interface for my pass to the new pass
manager, and that seems to work great.</div>
<div><br>
</div>
<div>I don't have as much experience using the new pass manager,
and I haven't tried running it by default. (For reference,
I'm doing most of my development based on LLVM 6.0 release at
the moment.) I noticed some talk from just under a year ago
about making the new pass manager the default. What's the
status of that work? Do the sanitizers work with the new pass
manager?</div>
</div>
</blockquote>
<br>
I think that it's pretty close, and in general, it works. The
sanitizers may be some of the last outstanding items.<br>
<br>
-Hal<br>
<br>
<blockquote type="cite"
cite="mid:CAGAvDYgwaa9B-tvOHR2pyKLVWsm_CczJtt+Vy0gJqPxiY3ySjQ@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>Cheers,</div>
<div>TB</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Sat, Aug 11, 2018 at 1:42 PM Michael Kruse
<<a href="mailto:llvmdev@meinersbur.de"
moz-do-not-send="true">llvmdev@meinersbur.de</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
you are using the Legacy PassManager (which is the default).
It<br>
generally does not allow passes to use analysis for sub
entities (e.g.<br>
a FunctionPass cannot use BasicBlockPass analysis). An
exception was<br>
hardcoded for ModulePass to use FunctionPass analsyis, called<br>
OnTheFlyManagers, but it will hold only one sub-pass at a time
(per<br>
type) and free the previous pass once you request a pass for a<br>
different function. This is why you get the memory error if
you<br>
continue to use the previous analysis.<br>
I once tried to get around this by invoking the analysis pass
without<br>
the pass manager. Unfortunately this is complex because the
Pass class<br>
needs an AnalysisResolver object that belongs to the
PassManager,<br>
<br>
However, there is a new pass manager that works differently.
It just<br>
stores all analysis for each entity until a pass invalidates
it. You<br>
might want to try that one. I suggest to look into the class<br>
ScalarEvolutionAnalysis (the equivalent of
ScalarEvolutionWrapperPass<br>
for the new pass manager) and see how it is used.<br>
<br>
Michael<br>
<br>
<br>
<br>
Am Sa., 11. Aug. 2018 um 09:16 Uhr schrieb TB Schardl via
llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>:<br>
><br>
> Hey LLVMDev,<br>
><br>
> I'm working on a ModulePass that uses ScalarEvolution
along with several other analyses. After some debugging, it
looks to me like ScalarEvolutionWrapperPass does not handle
memory correctly for this case. Here's my current
understanding of the problem.<br>
><br>
> ScalarEvolutionWrapperPass maintains a unique_ptr to a
ScalarEvolution. Calling getSE() dereferences this pointer.
Meanwhile runOnFunction() resets the pointer to point to a new
ScalarEvolution. As a result, runOnFunction destructs and
frees any ScalarEvolution the unique_ptr pointed to before.<br>
><br>
> The ModulePass I'm working on uses ScalarEvolution and
several other analysis FunctionPasses, including
DominatorTree, LoopInfo, OptimizationRemarkEmitter, and a
custom analysis pass I'm working on, which resembles
LoopInfo. To run ScalarEvolution and these other analysis
FunctionPasses in a ModulePass, the ModulePass creates lambdas
to get the analysis for a particular function, e.g.,<br>
><br>
> auto GetSE = [this](Function &F) ->
ScalarEvolution & {<br>
> return
this->getAnalysis<ScalarEvolutionWrapperPass>(F).getSE();<br>
> };<br>
><br>
><br>
> Later, when the ModulePass examines a particular
Function, it calls the appropriate lambda to get the analysis
for that Function.<br>
><br>
> The problem seems to arise when lambdas for other
analysis FunctionPasses run after calling the GetSE lambda,
e.g., when evaluating a statement like this:<br>
><br>
> for (Function &F : M)<br>
> Changed |= MyPassImpl(F, GetSE(F), GetDT(F), GetLI(F),
GetORE(F), ...).run();<br>
><br>
><br>
> It appears that these other analysis FunctionPasses can
cause ScalarEvolutionWrapperPass::runOnFunction() to rerun
after GetSE() returns a pointer to a ScalarEvolution, which
changes the underlying ScalarEvolution object that the wrapper
pass points to. As a result, the pointer originally obtained
from GetSE() points to invalid memory, and chaos ensues.
Running valgrind on the "opt -mypass" indicates that the
ScalarEvolution object used by MyPassImpl points to freed
memory.<br>
><br>
> I've been able to work around this problem, but I figured
I should raise the issue and see if you might have more
insights into this problem. For example, I'm not totally sure
why the other analysis FunctionPasses cause
ScalarEvolutionWrapperPass::runOnFunction() to rerun. I'm
also concerned about other analysis FunctionPasses, that might
suffer from the same problem. MemorySSAWrapperPass, for
example, uses a unique_ptr similarly to ScalarEvolution.<br>
><br>
> Cheers,<br>
> TB<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
> <a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
<!--'"--><br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>