cmd/compile: compilation of a package >100x slower with 1.20rc3

[aarzilli]

The package in question is https://github.com/benoitkugler/textlayout/fonts/glyphsnames in v0.3.0, with go 1.19:

$ go version
go version go1.19.1 linux/amd64
$ time go build

real	0m4,086s
user	0m5,970s
sys	0m0,447s

with go 1.20rc3 I got bored of waiting after 10 minutes, so it's at least 100x slower, but possibly a lot more (for all I know it could be in an infinite loop).

The code in question seems to have some very large (and very questionable) switch statements.

[mvdan]

GitHub source perma-link: https://github.com/benoitkugler/textlayout/tree/1c82cb9ca5cf9a53eecdd817414498959685547c/fonts/glyphsnames

The API looks small: https://pkg.go.dev/github.com/benoitkugler/textlayout/fonts/glyphsnames

[seankhliao]

there's a 12000 line / 6000 case switch in there

[seankhliao]

main » time go1.19.5 build -a               
go1.19.5 build -a  9.57s user 0.79s system 279% cpu 3.702 total

main » gotip version         
go version devel go1.21-e2fe35363d0 Mon Jan 23 10:02:20 2023 +0000 linux/amd64

main » time gotip build -a
gotip build -a  3983.07s user 58.04s system 771% cpu 8:43.65 total

[randall77]

Possibly https://go-review.googlesource.com/c/go/+/414894 .

[randall77]

Nope. Looks like the compiler is stuck/slow in prove. I think it is https://go-review.googlesource.com/c/go/+/410336
@wdvxdr1123 @cuonglm

[randall77]

Looks like all the OR operations are added for string equality - we do things like load 4 bytes, build a 32-bit value using shifts and ORs, then do a comparison with a 32-bit constant.
(The loads get combined into a single 32-bit load, but not until after the prove pass.)

[heschi]

Marking as a tentative release blocker.

[randall77]

Reverting CL 410336 is probably the simplest way forward. I'll do that tomorrow if no better ideas surface today.

[wdvxdr1123]

I agree about reverting CL 410336.

[cuonglm]

@randall77 could we use v.AuxInt to indicate that prove should ignore the value instead of updating to fact table?

[randall77]

@cuonglm Maybe, but I'd rather not. There's then this weird semantic-free mark that we'd have to ensure makes it to the prove pass. Can we CSE an OR with and without the mark? Do all rewrite rules have to propagate that mark? e.g.

(Or64 (Const64 <t> [c]) (Or64 (Const64 <t> [d]) x)) => (Or64 (Const64 <t> [c|d]) x)

If anything, maybe we could figure out when we don't need to prove anything about a value during the prove pass itself. Maybe if the result of an OR is only used in subsequent ORs and shifts, then don't record anything about it. Or something like that.

Or just make prove good enough to handle recording lots of facts without a big slowdown.