Change default build behavior to exclude building superpmi and altjits

[jashook]

Separate superpmi and the altjits built by the coreclr build into their own components. This would allow developers to opt into building them when they need them for testing or investigations with build.cmd -s clr.spmi+clr.altjit; however, when not needed the build throughput is increased ~10-15%.

[jashook]

/cc @BruceForstall

[BruceForstall]

@dotnet/jit-contrib -- this proposal contributes to improving the coreclr build time. It should be easy enough for JIT developers to build these components when needed. The plan is still to build them in the CI (but not the official build). This also would improve innerloop build times for JIT developers who don't need the altjits -- but can build them when they are needed.

[briansull]

I typically use the altjits very frequently when working on a checked or debug JIT. Please give easy instructions on how to continue building them. (i.e. simply adding +clr.altjit )

[davidwrighton]

I've addressed moving altjit building into the new clr.jits subset with pr #41126.

SuperPMI is still building as per normal though, and as its rather small, I'd prefer to leave it in its place. @BruceForstall if you think this is worth further investment, please let me know.

[BruceForstall]

The motivation here was to improve, especially, official build time. I don't know how much time it takes to build the superpmi components -- probably not too much -- but they also aren't needed in the official builds (probably).

So presumably @trylek can tell us how motivated we should be to move them to a possibly non-default group.

[trylek]

I must admit I wasn't participating in / locally validating Jarret's perf assessments. According to the item description he claims this filtering should speed up CoreCLR build by about 10-15%. Considering it takes something like 10-20 minutes on today HW, the speedup is supposed to reduce the build time by something like 2~3 minutes. While every minute counts w.r.t. the overarching goal to push official builds below 120 minutes, I suspect that this particular optimization is still relatively small potatoes from the viewpoint of the complete build graph; in other words, especially if such architects as Brian or David testify that the build steps in question are often useful in developer inner loop, I would be inclined to put this on a very back burner.

[davidwrighton]

To be honest, my change does not improve official build time... we now build more altjits than before in the official build, but they also become part of the full product in crossgen2, so I had redirected the speed work to be about inner loop build time, which may be better for developers who use a build command like build clr.runtime. Unfortunately build clr is now slower than before due to the new code that is compiled. As such, I think this workitem is now complete, and it might be useful to make a new workitem that would include details like... build fewer jits by merging some of these altjits into 1.

[trylek]

@davidwrighton - Thanks for sharing these additional insights - just for my education, does your suggestion to "build fewer jits by merging some of these altjits into 1" allude to your longer-term interest in making JIT target architecture-agnostic (driven by runtime parameters rather than compile-time settings) or is that about something else?

[davidwrighton]

It is exactly the idea of making the jit target architecture agnostic. In particular the arm and arm64 abis are extremely similar between windows and unix, and the differences are such that a few small if statements instead of #ifs would be sufficient to adjust the behavior of the jit. Unfortunately, the equivalent work for the differences between X64 Windows and X64 Unix would not be reasonable. So, effectively, I think it would be reasonable to move from the 7 altjits that are built as of now to 5, but work beyond that would be quite expensive. Its also true that the current change enables these cross targeting jits for more architectures than strictly necessary. It is likely that the x86 and arm32 builds of the sdk don't really need to support cross targetting support, and the need for crosstargeting from arm64 to all the other systems may also be unnecessary.