[GHC] #15051: -split-objs generates excessively many files on Windows

[GHC]

#15051: -split-objs generates excessively many files on Windows
-------------------------------------+-------------------------------------
        Reporter:  kanetw            |                Owner:  Phyx-
            Type:  bug               |               Status:  closed
        Priority:  highest           |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.5
  (CodeGen)                          |
      Resolution:  fixed             |             Keywords:
Operating System:  Windows           |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D4915
       Wiki Page:                    |  Phab:D4916
-------------------------------------+-------------------------------------

Comment (by Phyx-):

 > I've noticed this problem too, but I'm not sure getting rid of split-
 objs is the solution. The problem, it seems to me, is that it's (a)
 splitting with a Perl script, and (b) calling gcc with each and every
 single individual file produced.

 (a) is not the problem. The perl script just does a simple linear scan
 looking for split markers and breaks it up. The overall runtime of the
 split script is negligible.

 (b) It won't work without this. split-objs just exploits the fact that
 linkers pull in library code on demand. If no symbols in an object file in
 an archive is needed it's not pulled in.  split-section uses "linker
 stubs" to get the same effect, the tiny object files are pre-linked
 together to get one giant object file where each original .s file is a new
 stub.  Passing all the .s files to the assembler will cause it to merge
 the contents of the sections and you'd get one linker stub. The net effect
 would be the same as not splitting to begin with. While you could force
 the creation of a linker stub with a `.file` directive for each part, the
 result still won't be the same as your `.text` section header will still
 be merged.

 > Is it possible to get rid of the Perl script, at least on Windows, by
 specializing the split-objects procedure for Windows x86/x64 builds and
 then using gcc to build many assembly files at a time?

 Not really, as I've explained above.

 > Actually, now that I think about it, why is it even using gcc to convert
 the assembly files into object files in the first place? Doesn't it
 convert the code directly into an object file when split-objs isn't used?

 No, GHC doesn't have an assembler or static linker. It always uses an
 external program for both of these cases.  It only has a runtime linker
 for GHCi and Template Haskell.

 As it stands, `-split-objs` is simply a dead approach, it's better to
 invest the time into getting `-split-sections` working, which doesn't rely
 on hacks.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15051#comment:16>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler