[llvm-dev] Need guidance to work on NEW PASS managers bugs

Sun May 6 01:59:11 PDT 2018

Hello all,

After reading OptBisect and DebugCounter related code and playing bit
around it I have following simple design:

- Add a debug counter for opt-bisect. Initilize it against option
-opt-bisect-limit=<limit>.
- DebugCounter is a singleton class so can be accessed by both new and
legacy passmanager.
  We may need few more static method like getCounterIdForName(std::string
&Name) etc.
- Use it to decide if this pass is required to be executed or not.
- For new passmaager just before executing run() for a pass we can check
this counter.
- For legacy pass manager we can directly use this debug counter in
skipFunction()/skipModule() etc method.
- There is already FIXME: added for moving getDescription() from OptBisect
class to respective
  IR units like Loop, Region etc. So that new pass manager can also use
those methods.
- However to support feature added in this https://reviews.llvm.org/D44464
we may need to add a callback function
  pointer that can be set and if present use it instead for normal counter
value check to decide if a pass should
  be executed or not. Or some other mechanism to provide this feature.
- I am not completely sure but if we are able provide custom callback
feature then we may be able to remove OptBiset and OptPassGate
  class.

Anything missed here?

Please share your thoughts.
-Vivek

On Thu, May 3, 2018 at 12:34 AM, Kaylor, Andrew <andrew.kaylor at intel.com>
wrote:

> As a point of clarification, optnone is already being handled by the pass
> itself in the legacy implementation. The skip[IR unit] functions are
> provided by the pass base classes, and the attribute is checked there. This
> happens any time the legacy wrapper is run, no matter how it is run.
>
>
>
> Regarding the opt-bisect design, I’m not particularly fond of the managed
> static either, but I do want to mention a couple of things that I don’t
> want to lose about the current solution. First, it is important that we
> continue to print out information about the passes and the IR units as they
> are run or skipped. Our QA team uses this information as a first step in
> identifying the source of failures. Second, a change was recently
> introduced to generalizing the opt bisect interface (as obtained through
> the LLVMContext) so that clients can plug in other mechanism that use other
> criteria for stopping compilation.
>
>
>
> -Andy
>
>
>
> *From:* Philip Pfaffe [mailto:philip.pfaffe at gmail.com]
> *Sent:* Wednesday, May 02, 2018 3:57 AM
> *To:* vivek pandya <vivekvpandya at gmail.com>
> *Cc:* Kaylor, Andrew <andrew.kaylor at intel.com>; llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] Need guidance to work on NEW PASS managers bugs
>
>
>
> Hi Vivek,
>
>
>
> bisect and optnone are certainly low hanging fruit in terms of
> implementation. On the other hand they need a cleaner design than they have
> now. E.g., OptBisect today is a managed static, which we absolutely should
> get rid of. Instead, bisect functionality can be much more cleanly
> implemented on top of the debug counters!
>
>
>
> While the function call for optnone doesn't strike me as similarly bad,
> there is another angle there. I think optnone should be handled by the
> passes, and not the manager. Considering running the pass outside of a
> manager, you'd probably expect it to respect optnone.
>
>
>
> In summary, while easy to implement, these things need reconsidering and a
> solid RFC. So if you want to work on this, you should draft such a design
> document and post it to the list to collect comments and requests from the
> community.
>
>
>
> Cheers,
>
> Philip
>
>
>
>
>
> 2018-05-01 21:01 GMT+02:00 vivek pandya via llvm-dev <
> llvm-dev at lists.llvm.org>:
>
>
>
>
>
> On Tue, May 1, 2018 at 10:52 PM, Kaylor, Andrew <andrew.kaylor at intel.com>
> wrote:
>
> Hi Vivek,
>
>
>
> Have you read the mailing list threads on this topic? I don’t believe
> we’re quite ready to make the switch yet. There was a discussion last
> October about what was left to be done. I’m sure it has been discussed
> since then too. Here’s a link to the start of the October discussion.
>
>
>
> http://lists.llvm.org/pipermail/llvm-dev/2017-October/118280.html
>
> Yes I have gone through that mail chain. One thing mentioned in that was
> Code Generation does not use new PM so I wanted to start working in that
> direction.
>
>
>
> If you’d like to get involved, one possible area you could contribute is
> adding optbisect/optnone support as mentioned in this bug:
>
>
>
> https://bugs.llvm.org/show_bug.cgi?id=28316
>
>
>
> If that looks like something you’re interested in I can offer some
> guidance with it.
>
> Sure I am happy to work on it. Could you please update the bug with your
> thoughts on how that needs to be done?
>
>
>
> -Vivek
>
>
>
> Thanks,
>
> Andy
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *vivek
> pandya via llvm-dev
> *Sent:* Saturday, April 28, 2018 9:23 AM
> *To:* llvm-dev <llvm-dev at lists.llvm.org>
> *Subject:* [llvm-dev] Need guidance to work on NEW PASS managers bugs
>
>
>
> Hello LLVM-Devs,
>
>
>
> I am trying to get some starting points for working on following new pass
> manager related bugs:
>
>
>
> https://bugs.llvm.org/show_bug.cgi?id=28322 [PM] Remove use of old PM in
> the middle-end.
>
>
>
> https://bugs.llvm.org/show_bug.cgi?id=28323 [PM] Use new PM in production
> for Clang, LLD, libLTO, etc. middle-end
>
> https://bugs.llvm.org/show_bug.cgi?id=28321 [PM] Remove use of old PM in
> the backend
>
>
>
> I read related code but did not get a good starting point.
>
> Can someone guide me through this? Can we add more details to these bugs?
> Or can we further divide these bugs to smaller workable items?
>
>
>
> Any help will be appreciated.
>
>
>
> Thanks,
>
> Vivek
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180506/013f658c/attachment.html>