<div dir="ltr">opt-bisect is often used to debug why a program compiled at -O0 produces different output to a program compiled at -O1 or -O2. We want to eliminate the bad pass/optimization but still produce a working executable.<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><br></div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">~Craig</div></div><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 26, 2018 at 11:41 AM Philip Pfaffe via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
It kinda depends on user expectations.<br>
What do you really expect as a result of your compilation when you
set -opt-bisect-limit=X?<br>
Do you just get a resulting IR and scan for the bad pattern?<br>
Then you dont care about pass sequences and do brute-force bisect.<br></div></blockquote><div>This is what I'd expect. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
Do you expect to get a runnable code at the end and check for buggy
run-time behavior?<br>
Then you need to keep the passes that are required to produce
runnable code.<br>
In our Java JIT compiler we have quite a number of passes where we
lower the semantics<br>
to C level and those lowerings are absolutely required for the code
to be runnable.<br>
<br>
regards,<br>
Fedor.<br>
<br>
<div class="m_5417777755896697349m_-3286038402771901473moz-cite-prefix">On 09/26/2018 08:47 PM, Philip Pfaffe
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Fedor,
<div><br>
</div>
<div>can you make an example where a pass actually needs to
opt-out? Because IMO, bisect should quite literally to
DebugCounter-style skip every step in every ::run method's
loop. Passes should not even be concerned with this.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Philip</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Wed, Sep 26, 2018 at 6:54 PM Fedor Sergeev via
llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Greetings!<br>
<br>
As the generic Pass Instrumentation framework for new pass
manager is <br>
finally *in*,<br>
I'm glad to start the discussion on implementation of
-opt-bisect <br>
through that framework.<br>
<br>
As it has already been discovered while porting other features
(namely, <br>
-time-passes)<br>
blindly copying the currently existing legacy implementation
is most <br>
likely not a perfect<br>
way forward. Now is a chance to take a fresh look at the
overall <br>
approach and perhaps<br>
do better, without the restrictions that legacy pass manager
framework <br>
imposed on<br>
the implementation.<br>
<br>
Kind of a summary of what we have now:<br>
- There is a single OptBisect object, requested through
LLVMContext<br>
(managed as ManagedStatic).<br>
<br>
- OptBisect is defined in lib/IR, but does use analyses,<br>
which is a known layering issue<br>
<br>
- Pass hierarchy provides skipModule etc helper functions<br>
<br>
- Individual passes opt-in to OptBisect activities by
manually <br>
calling skip* helper functions<br>
whenever appropriate<br>
<br>
With current state of new-pm PassInstrumentation potential
OptBisect <br>
implementation<br>
will have the following properties/issues:<br>
- OptBisect object that exists per compilation pipeline,
managed <br>
similar to PassBuilder/PassManagers<br>
(which makes it more suitable for use in parallel
compilations)<br>
<br>
- no more layering issues imposed by implementation since <br>
instrumentations by design<br>
can live anywhere - lib/Analysis, lib/Passes etc<br>
<br>
- since Codegen is still legacy-only we will have to make a
joint <br>
implementation that<br>
provides a sequential passes numbering through both
new-PM IR and <br>
legacy Codegen pipelines<br>
<br>
- as of right now there is no mechanism for opt-in/opt-out,
so it <br>
needs to be designed/implemented<br>
Here I would like to ask:<br>
- what would be preferable - opt-in or opt-out?<br>
<br>
- with legacy implementation passes opt-in both for
bisect and <br>
attribute-optnone support at once.<br>
Do we need to follow that in new-pm implementation?<br>
<br>
Also, I would like to ask whether people see current user
interface for <br>
opt-bisect limiting?<br>
Do we need better controls for more sophisticated bisection?<br>
Basically I'm looking for any ideas on improving opt-bisect
user <br>
experience that might<br>
affect design approaches we take on the initial
implementation.<br>
<br>
regards,<br>
Fedor.<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>