An alternative might be to enhance the existing rule-based system. Something that took costs into account would allow the larger rule to fire before it was invalidated by sub-rules. For example, iburg. I've worked with these in the past, they're nice. In some cases you can replace compile-time dynamic programming with precompiled static tables, but those are less flexible and also lead to a certain amount of brain-hurt in their implementation.

@dr2chase that sounds helpful, but unrelated to improved debugging tools for rules. If anything, it'd make the need for good debugging even higher.

I didn't have that problem the two times I've used such a code generator. Normally they "just work", and an annoying class of problems (they ones that bit you in that CL) vanishes.

I am imagining that the transformation history of the SSA graphs could perhaps be modeled as something like the organization of Git objects , and making each SSA rule act like the "author" of the commits. Then users can have a git log -L equivalent or a more flexible query language to look up the desired information. Just leave me alone if this sounds stupid.

Something that took costs into account would allow the larger rule to fire before it was invalidated by sub-rules.

@dr2chase I really wanted this while working on CL 43157.

Is this still wanted by anyone other than @josharian ? :)

ping @josharian

also ping @minux @dr2chase

I still think this would be helpful (at least unless/until we have a more sophisticated rule system, such as described by @dr2chase above). The problem is that I'm still not entirely clear on what output would be most helpful.

Here's a new (simpler) idea that mimics what I sometimes do during debugging:

Add a flag to the rule generator (like -log) that accepts a file:line. For the rule on that file line, generate code to spew debug output. E.g. rewrite:

	// match: (Add64 (Const64 [c]) (Const64 [d]))
	// cond:
	// result: (Const64 [c+d])
	for {
		_ = v.Args[1]
		v_0 := v.Args[0]
		if v_0.Op != OpConst64 {
			break
		}
		c := v_0.AuxInt
		v_1 := v.Args[1]
		if v_1.Op != OpConst64 {
			break
		}
		d := v_1.AuxInt
		v.reset(OpConst64)
		v.AuxInt = c + d
		return true
	}

into something like this:

	// match: (Add64 (Const64 [c]) (Const64 [d]))
	// cond:
	// result: (Const64 [c+d])
	for {
		fmt.Println("check ", v.LongString())
		_ = v.Args[1]
		v_0 := v.Args[0]
		fmt.Println("\tv_0=", v_0.LongString())
		if v_0.Op != OpConst64 {
			fmt.Println("\tv_0.Op != OpConst64")
			break
		}
		c := v_0.AuxInt
		fmt.Println("\tc=", c.LongString())
		v_1 := v.Args[1]
		fmt.Println("\tv_1=", v_1.LongString())
		if v_1.Op != OpConst64 {
			fmt.Println("\tv_1.Op != OpConst64")
			break
		}
		d := v_1.AuxInt
		fmt.Println("\td=", v_1.AuxInt)
		v.reset(OpConst64)
		v.AuxInt = c + d
		fmt.Println("\tv.AuxInt=", c+d)
		fmt.Println("\tMATCH")
		return true
	}

I think in practice it'll just take a bit of experimenting and iterating to find out what is helpful.

I think this is a plausible approach -- I looked into what it would take to add rule system w/ all the predicates we have, and it was more than I wanted to deal with right now.

Change https://golang.org/cl/176718 mentions this issue: cmd/compile: debug rewrite

Change https://golang.org/cl/183239 mentions this issue: cmd/compile: debug rewrite, enhanced