Split the big jit files to allow better GitHub experience.

[sandreenko]

GitHub doesn't support showing huge files, for example, https://github.com/dotnet/coreclr/blob/master/src/jit/flowgraph.cpp has 25680 lines, but GitHub will show you only the first 14908. And it doesn't show any warning that the shown part is not full.

The same happens with reviewing diffs.

GitHub limits are not clear, https://help.github.com/en/articles/limits-for-viewing-content-and-diffs-in-a-repository tells about 1MB for text files, but flowgraph is smaller, I wrote them a question about code file sizes limits.

Once we get the actual limits we will be able to determinate the list of files that we need to split.

See also disscusion in dotnet/coreclr#26392 (comment).

cc @dotnet/jit-contrib

category:implementation
theme:jit-coding-style
skill-level:beginner
cost:medium

[danmoseley]

Browser issue? I see all 25K lines at https://github.com/dotnet/coreclr/blob/master/src/jit/flowgraph.cpp. It takes time though and that doesn't mean smaller isn't better.

[Joe4evr]

There was a discussion somewhat similar to this back when this repo was still new: https://github.com/dotnet/coreclr/issues/408#issuecomment-77922359

[sandreenko]

I got the answer from the GitHub support:

We currently limit blob displaying to around 500kb of data, anything more we truncate in the UI. You can view the raw by clicking through.

So I think it would be rational to make a 400kb limit for all files that we have, it means we need to split 9 files:

10/14/2019  05:29 PM           413,140 emitarm64.cpp
10/14/2019  05:29 PM           435,201 lsra.cpp
10/24/2019  03:32 PM           447,708 compiler.h <- header!
10/14/2019  05:29 PM           451,531 codegencommon.cpp
10/24/2019  03:32 PM           462,582 emitxarch.cpp
10/24/2019  03:32 PM           637,322 gentree.cpp
10/24/2019  03:32 PM           734,066 morph.cpp
10/24/2019  03:32 PM           823,537 importer.cpp
10/24/2019  03:32 PM           920,170 flowgraph.cpp

[mikedn]

Any idea how they can be split in a rational manner (e.g. not by cutting it in half and having something like importer1.cpp and importer2.cpp 😁)?

For flowgraph.cpp I'm sure we can find code in it that's not actually flowgraph related and perhaps that there's enough of it to move it somewhere else and matter. Not sure about the rest.

[sandreenko]

Any idea how they can be split in a rational manner (e.g. not by cutting it in half and having something like importer1.cpp and importer2.cpp 😁)?

For flowgraph.cpp I'm sure we can find code in it that's not actually flowgraph related and perhaps that there's enough of it to move it somewhere else and matter. Not sure about the rest.

I think it should be individual in each case, and I think compiler.h is the biggest problem.

For example, for importer, it is probably enough to extract impImportBlockCode to solve that (it is 5000+ lines function).

Also, we can extract Compiler::verification logic or intrinsic functions.