[llvm-bugs] [Bug 34326] New: After r296476, massive compile time increases on large functions

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=34326

            Bug ID: 34326
           Summary: After r296476, massive compile time increases on large
                    functions
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: dimitry at andric.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 19042
  --> https://bugs.llvm.org/attachment.cgi?id=19042&action=edit
Tests case that takes more than an hour to compile after r296476

I received a report from the maintainer of the FreeBSD cad/stepcode port (see
also http://stepcode.org/), that clang 5.0.0 took so long to build it, that the
job was killed after 2 hours.  However, with clang 4.0.0, it took about 10
minutes.

Bisection shows that this has regressed with https://reviews.llvm.org/rL296476
("In visitSTORE, always use FindBetterChain, rather than only when UseAA is
enabled").

It took a look, and it turns out that stepcode generates large C++ files,
consisting of one function body, sometimes having tens of thousands of lines,
similar to:

    [...]
    node = new OrList;
    ((MultList *)node)->appendList( child );
    next[2]->prev = node;
    node->next = next[2];
    next[2] = node;
    node = new SimpleList( "component_path_shape_aspect" );
    next[2]->prev = node;
    node->next = next[2];
    next[2] = node;
    node = new SimpleList( "connection_zone_interface_plane_relationship" );
    next[2]->prev = node;
    node->next = next[2];
    next[2] = node;
    node = new SimpleList( "device_terminal_map" );
    next[2]->prev = node;
    node->next = next[2];
    next[2] = node;
    node = new SimpleList( "modified_pattern" );
    next[2]->prev = node;
    node->next = next[2];
    next[2] = node;
    node = new SimpleList(
"make_from_functional_unit_terminal_definition_relationship" );
    next[2]->prev = node;
    node->next = next[2];
    next[2] = node;

For some reason, this type of construct makes clang 5.0.0 spend enormous
amounts of time optimizing it.  However, that *only* applies to i386, e.g.
32-bit x86!  When targeting x86_64, the effect is much less drastic.

Compile times (in seconds) of clang 5.0.0 when targeting i386, and building the
various files of the stepcode port, together with the number of lines in the
(usually generated) source file:

time     lines  filename
=======  =====
============================================================================================
4809.23  28345  schemas/sdai_wip210e3/compstructs.cc
2164.37  19658  schemas/sdai_cd209/compstructs.cc
2056.54  15806  schemas/sdai_ap210e2/compstructs.cc
1545.19  16679  schemas/sdai_cd242/compstructs.cc
446.49   7667  schemas/sdai_ap203e2/compstructs.cc
273.96   6297  schemas/sdai_ap214e3/compstructs.cc
187.16    103 
schemas/sdai_ap239/SdaiAP239_PRODUCT_LIFE_CYCLE_SUPPORT_ARM_LF_unity_types.cc
163.39    440 
schemas/sdai_cd209/SdaiAP209_MULTIDISCIPLINARY_ANALYSIS_AND_DESIGN_MIM_LF_unity_types.cc
130.02   2232
schemas/sdai_cd209/SdaiAP209_MULTIDISCIPLINARY_ANALYSIS_AND_DESIGN_MIM_LF_unity_entities.cc
122.15    290 
schemas/sdai_cd242/SdaiAP242_MANAGED_MODEL_BASED_3D_ENGINEERING_MIM_LF_unity_types.cc

E.g. the top file takes more than an *hour* to compile!  The same results, but
then targeting x86_64:

time     lines  filename
=======  =====
============================================================================================
184.90  28345  schemas/sdai_wip210e3/compstructs.cc
115.08    103 
schemas/sdai_ap239/SdaiAP239_PRODUCT_LIFE_CYCLE_SUPPORT_ARM_LF_unity_types.cc
110.00    440 
schemas/sdai_cd209/SdaiAP209_MULTIDISCIPLINARY_ANALYSIS_AND_DESIGN_MIM_LF_unity_types.cc
106.70    292
schemas/sdai_wip210e3/SdaiAP210_ELECTRONIC_ASSEMBLY_INTERCONNECT_AND_PACKAGING_DESIGN_MIM_LF_unity_types.cc
 90.73    290 
schemas/sdai_cd242/SdaiAP242_MANAGED_MODEL_BASED_3D_ENGINEERING_MIM_LF_unity_types.cc
 88.77   2232
schemas/sdai_cd209/SdaiAP209_MULTIDISCIPLINARY_ANALYSIS_AND_DESIGN_MIM_LF_unity_entities.cc
 81.87   2174
schemas/sdai_wip210e3/SdaiAP210_ELECTRONIC_ASSEMBLY_INTERCONNECT_AND_PACKAGING_DESIGN_MIM_LF_unity_entities.cc
 73.92  19658  schemas/sdai_cd209/compstructs.cc
 64.82   1734 
schemas/sdai_cd242/SdaiAP242_MANAGED_MODEL_BASED_3D_ENGINEERING_MIM_LF_unity_entities.cc
 61.42    189
schemas/sdai_ap210e2/SdaiAP210_ELECTRONIC_ASSEMBLY_INTERCONNECT_AND_PACKAGING_DESIGN_MIM_LF_unity_types.cc

I have attached the top file from the i386 build as a test case, which is
~69000 lines, of which ~28000 lines are in the main gencomplex() function. 
There is also a shell script to show the exact compile options.

Since r296476 is already saying something about a "fixup of 32-bit aliasing
sign offset bug in DAGCombiner", I am assuming there is still another 32-bit
bug lurking in there somewhere, with rather disastrous consequences.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170825/6e560934/attachment.html>