[llvm-dev] RFC: Enabling Module passes post-ISel

[Renato Golin via llvm-dev]

On 19 July 2016 at 15:16, James Molloy via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I think that fundamentally users of LLVM should be able to opt-in to more
> aggressive or intensive computation at compile time if they wish. Users'
> needs differ, and while a 33% increase in clang LTO is absolutely out of the
> question for some people, for those developing microcontrollers or HPC
> applications that may well be irrelevant. Either the volume of code expected
> is significantly smaller or they're happy to trade off compile time for
> expensive server time. That does not mean that we shouldn't strive for a
> solution that can be acceptable by all users. On the other hand making
> something opt-in makes it non-default, and that increases the testing
> surface.

I agree with this reasoning in principle. LTO is already an example of
that trade off.

The problem is, as with LTO, how to make sure those options don't
bit-rot, without duplicating testing infrastructure. I don't have a
good solution for that.

Another thing that this raises (and we should have done that for LTO)
is monitoring not just compile and run times, but also compile and run
time memory consumption.

I believe some people are already doing it ad-hoc, but it would be
good to have that, for example, in LNT.


> So my suggestion is that we go with Matthias' idea - do the small amount of
> refactoring needed to allow MachineModulePasses on an opt-in basis. The
> knobs to enable that opt-in might need some more bikeshedding.

We have prior art on that, so I think it should be mostly fine.
Bikeshedding won't be necessary, not for the flags, I think.

We just have to make sure this is not something that will encumber
other changes in the area (and I'm being vague on purpose, as I can't
think of anything). :)

cheers,
--renato