similar to: RFC: New support for triaging optimization-related failures in front ends

Hi Andy, > On Mar 25, 2016, at 11:41 AM, Kaylor, Andrew via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The Intel C++ compiler has long had an internal facility to help our development teams track down the source of optimization related bugs by allowing a sort of binary search in which optimization passes and even individual optimizations are selectively disabled in response

> On Mar 25, 2016, at 11:56 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Andy, > >> On Mar 25, 2016, at 11:41 AM, Kaylor, Andrew via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> The Intel C++ compiler has long had an internal facility to help our development teams track down the

> On Mar 25, 2016, at 12:13 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > > Hi Mehdi, > > I started by trying to implement a single number approach, but it doesn’t allow quite the approach I wanted in terms of isolating individual functions. Do you have an example where it matters? I wonder if there are enough real-world use case that justify the complexity?

Hi Mehdi, I started by trying to implement a single number approach, but it doesn't allow quite the approach I wanted in terms of isolating individual functions. Also, I think that there would be problems with that once parallel function optimization is enabled. I am open to revisiting that approach to see if the problems I had with it can be resolved. -Andy From: mehdi.amini at apple.com

> On Mar 25, 2016, at 12:10 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Mar 25, 2016, at 11:56 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi Andy, >> >>> On Mar 25, 2016, at 11:41 AM, Kaylor, Andrew via llvm-dev <llvm-dev at

Maybe someone on the list who knows about GHC internals (I don't) can chime in here, but GHC has (had?) a concept of "optimization fuel": http://blog.ezyang.com/2011/06/debugging-compilers-with-optimization-fuel/ that is very similar to what Mehdi is suggesting. -- Sanjoy On Fri, Mar 25, 2016 at 12:37 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >

Andy, I'd love to see this feature. I wouldn't care too much wether the interface is a single number or two numbers, but if possible print the name of the function and the name of the pass that was just skipped so the developers knows where to start looking. - Matthias > On Mar 25, 2016, at 12:13 PM, Kaylor, Andrew via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi

> In the swift-world we use utils/bisect + a single number all the time + extra verifications. It works really well. Can you describe to me what you mean by that exactly? Are you using the single number in the LLVM back end or somewhere else? From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Michael Gottesman via llvm-dev Sent: Friday, March 25, 2016 12:35 PM To:

> On Mar 25, 2016, at 4:30 PM, Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Andy, > > I'd love to see this feature. I wouldn't care too much wether the interface is a single number or two numbers, but if possible print the name of the function and the name of the pass that was just skipped so the developers knows where to start looking. We do

And as we are on the topic of bisecting/diagnosing scripts I attached my personal script I used before. You give it two directories with assembly files (typically from a known good compiler and a "bad" compiler). The script will then go on and create permutations by picking all files from the "good" directory and combining them with a single file form the "bad"

I will describe the complete process for completeness thus hopefully forestalling all questions [tell me if I did not ; )]. There is not much to it TBH. ./utils/bisect is a dumb python script that allows for arbitrary bisecting via the exit status of a script it runs . The way you use it is you write a script (lets call it test.sh). Then you invoke: ./utils/bisect --start=N --end=M ./test.sh

Ok I cleaned it up and added some explaining comments. It's in llvm/utils/abtest now. - Mathias > On Mar 25, 2016, at 4:40 PM, Michael Gottesman <mgottesman at apple.com> wrote: > > >> On Mar 25, 2016, at 4:37 PM, Matthias Braun <matze at braunis.de <mailto:matze at braunis.de>> wrote: >> >> And as we are on the topic of bisecting/diagnosing

> On Mar 25, 2016, at 4:37 PM, Matthias Braun <matze at braunis.de> wrote: > > And as we are on the topic of bisecting/diagnosing scripts I attached my personal script I used before. > > You give it two directories with assembly files (typically from a known good compiler and a "bad" compiler). The script will then go on and create permutations by picking all files

I've worked on a compiler with a counter, but for individual optimisations, not just passes. It was incredibly useful! In the llvm world, it would let you bisect exactly which instcombine, dagcombine, or whatever causes an issue. I support the addition of a pass counter if it helps bisecting, but just wanted to point out that this can be as fine grained as the community is willing to accept.

I agree that the more fine grained this becomes the more useful it can be. I’ve updated my prototype to use a single number approach. I’m going to clean this up and post a review in the next day or two. -Andy From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Pete Cooper via llvm-dev Sent: Friday, March 25, 2016 10:22 PM To: Matthias Braun <matze at braunis.de> Cc:

Hi Greg, Thanks for your input! I’d love to see this evolve into something that would let us track problems to individual IR changes. My thinking is that starting with passes gives us something that will get us maybe 70% of the functionality in one easy step, then individual passes can be instrumented as anyone has time or need to get us the rest of the way there. Your max_opt option sounds

Since introducing the new TargetTransformInfo analysis, there has been some confusion over the role of target heuristics in IR passes. A few patches have led to interesting discussions. To centralize the discussion, until we get some documentation and better APIs in place, let me throw out an oversimplified Straw Man for a new pass pipline. It serves two purposes: (1) an overdue reorganization of

On 7/16/2013 11:38 PM, Andrew Trick wrote: > Since introducing the new TargetTransformInfo analysis, there has been some confusion over the role of target heuristics in IR passes. A few patches have led to interesting discussions. > > To centralize the discussion, until we get some documentation and better APIs in place, let me throw out an oversimplified Straw Man for a new pass pipline.

On Tue, Jun 14, 2016 at 11:29 PM, Xinliang David Li <davidxl at google.com> wrote: > > > On Thu, Jun 9, 2016 at 3:26 AM, Sean Silva <chisophugis at gmail.com> wrote: > >> >> >> On Wed, Jun 8, 2016 at 8:14 PM, Xinliang David Li <davidxl at google.com> >> wrote: >> >>> >>> >>> On Wed, Jun 8, 2016 at 4:38 PM, Sean

I ran across an interesting case and wanted to share it. I'm not proposing any particular changes, but the experience seemed interesting to discuss. First, a bit of background. An LLVM Loop models a specific type of cycle in the CFG. Not all cycles are Loops. Many of our optimization transforms are phrased over loops, which means that a non-loop cycle tends to be less well optimized.