[llvm-dev] Opt Bisect layering

Kaylor, Andrew via llvm-dev llvm-dev at lists.llvm.org
Wed Mar 21 13:51:50 PDT 2018


There is a patch under review right now from someone who wants to provide a mechanism to replace OptBisect as the pass gate keeping mechanism.

https://reviews.llvm.org/D44464

Possibly we could take this opportunity to move OptBisect to a different layer, though I don’t know where else it would belong.

The other possibility is that we could have the caller pass in a description instead of a pointer to the pass and the IR unit. OptBisect isn’t doing anything with them other than building a string for output.

-Andy

From: David Blaikie [mailto:dblaikie at gmail.com]
Sent: Wednesday, March 21, 2018 12:09 PM
To: llvm-dev <llvm-dev at lists.llvm.org>; Kaylor, Andrew <andrew.kaylor at intel.com>; Friedman, Eli <efriedma at codeaurora.org>
Subject: Opt Bisect layering

So I'm poking around trying to improve the layering of LLVM (using an internal strict modular build as a motivation/tool to identify issues) & came across a layering violation in the OptBisect implementation.

This feature is implemented in lib/IR, but includes several headers from include/llvm/Analysis - which would create a circular dependency if not for the fact that all the headers it includes are header-only (templates).

Any ideas about how this could/should be fixed? Perhaps these analyses should be moved into somewhere more common - but I don't know there's anywhere more (or less) common than lib/IR itself (since I assume they depend on IR & that's where OptBisect is, so they can't be lower/higher than that).

Does that sound OK? Anyone have other/better ideas?

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180321/57e9e57d/attachment-0001.html>


More information about the llvm-dev mailing list