[Bug debug/101064] New: long compile time in var_tracking for Go package

[Bug debug/101064] New: long compile time in var_tracking for Go package

[thanm at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101064

            Bug ID: 101064
           Summary: long compile time in var_tracking for Go package
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: thanm at google dot com
  Target Milestone: ---

Created attachment 51008
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51008&action=edit
testcase to reproduce (Go files, some profile reports)

Building the attached Go package with gccgo results in a very long compile
time, apparently due to var_tracking. To reproduce, unpack the tar file and
build with either:

  A) go clean -cache; go build .

or

  B) gccgo  -c -O2 -g -m64 -fgo-pkgpath=xyz ./aenum.go ./avx_optabs.go


[Note: this issue is first posted on the main Go issue tracker at
https://github.com/golang/go/issues/46600; more details there].

This is a fairly modest sized Go package; building it with the main (non-gcc)
Go compiler takes about a third of a second (user + sys, reported by
/bin/time).

For gccgo, building with -O0 takes about a second, but the time taken at -O1
and -O2 are much longer:

  -O1:     450 seconds
  -O2:     257 seconds

Along with the test case, I am attaching some profiles collected using 'pprof'.

The pass consuming the extra compile time appears to be variable_tracking; from
the profiles the problem looks to be related to alias analysis / memory
disambiguation.

[Bug debug/101064] long compile time in var_tracking for Go package

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101064

--- Comment #1 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Ian Lance Taylor <ian@gcc.gnu.org>:

https://gcc.gnu.org/g:8a8a7d332d5d01db5aea7336a36d9fd71a679fb1

commit r12-1913-g8a8a7d332d5d01db5aea7336a36d9fd71a679fb1
Author: Ian Lance Taylor <iant@golang.org>
Date:   Mon Jun 28 16:47:55 2021 -0700

    compiler: in composite literals use temps only for interfaces

    For a composite literal we only need to introduce a temporary variable
    if we may be converting to an interface type, so only do it then.
    This saves over 80% of compilation time when using gccgo to compile
    cmd/internal/obj/x86, as the GCC middle-end spends a lot of time
    pointlessly computing interactions between temporary variables.

    For PR debug/101064
    For golang/go#46600

    Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/331513

[Bug debug/101064] long compile time in var_tracking for Go package

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101064

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Ian Lance Taylor
<ian@gcc.gnu.org>:

https://gcc.gnu.org/g:528ed794016472a209d6cfaa921307f30eee58da

commit r11-8663-g528ed794016472a209d6cfaa921307f30eee58da
Author: Ian Lance Taylor <iant@golang.org>
Date:   Tue Jun 29 11:00:13 2021 -0700

    compiler: in composite literals use temps only for interfaces

    For a composite literal we only need to introduce a temporary variable
    if we may be converting to an interface type, so only do it then.
    This saves over 80% of compilation time when using gccgo to compile
    cmd/internal/obj/x86, as the GCC middle-end spends a lot of time
    pointlessly computing interactions between temporary variables.

    For PR debug/101064
    For golang/go#46600

    Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/331513

[Bug debug/101064] long compile time in var_tracking for Go package

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101064

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at airs dot com

--- Comment #3 from Ian Lance Taylor <ian at airs dot com> ---
I've committed fixes to the Go frontend that speed up this test case
significantly by generating fewer temporary variables.

[Bug debug/101064] long compile time in var_tracking for Go package

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101064

--- Comment #4 from Ian Lance Taylor <ian at airs dot com> ---
Created attachment 51086
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51086&action=edit
C test case

[Bug debug/101064] long compile time in var_tracking for Go package

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101064

--- Comment #5 from Ian Lance Taylor <ian at airs dot com> ---
I have attached a C test case that demonstrates the problem.  The C case may be
somewhat worse because I had to use ordinary variables, whereas the Go test
case is used compiler-generated temporary variables.

When I compiled the C test case with mainline GCC with "-g -O2" on my laptop
the compilation takes 20 minutes, and according to -ftime-report 91% of that
time is spent on var-tracking:

 var-tracking dataflow              : 541.98 ( 44%)   0.02 (  2%) 542.26 ( 44%)
 1288k (  0%)
 var-tracking emit                  : 575.86 ( 47%)   0.04 (  4%) 576.31 ( 47%)
 3125k (  0%)

This test case is, of course, generated code, as is the original Go test case
(the generated Go code is
https://go.googlesource.com/go/+/refs/heads/master/src/cmd/internal/obj/x86/avx_optabs.go).

The var-tracking pass already has a fast exit for functions with lots of basic
blocks.  Perhaps it also needs a fast exit for functions that are very long
even if they don't have many basic blocks.