Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Don't generate Clambda constants during Cmmgen, etc. #2280
This patch is a prerequisite of a forthcoming patch that improves the types used to represent symbols (names of statically-allocated entities) throughout the middle end and backend. This in turn is needed for the
I think a good general principle, when writing a pass that operates on some particular IR, is to avoid generating constructs from previous IRs and sending them back through part of the current pass. Instead, it is better to refactor the current pass so that the constructs you want can be generated directly in your current language.
This patch changes
There are a couple of other related changes that I thought reasonable to include with this patch, since our workflow management becomes difficult if there are just too many pull requests. One of them passes the list of constants, for the classic Closure mode, through from
@lthls Could you please look at this? (Some amount of this is just moving code upwards in
The patch looks fine, except for a few small issues:
Well spotted. I've pushed a patch that should cause Closure to lift empty arrays and then share the resulting constants. As far as I can see Flambda already does this (see
Regarding other constants not shared in Cmmgen, I am minded not to worry about this, as any potential size increase seems likely to be minor (especially given what you say about the relevant optimisation being difficult to trigger)---and in any case, we have a medium-term story for doing unboxing in a more principled manner inside the next version of Flambda.
I've reinstated the variables instead of strings for the boxed integer operations symbols. (All of the symbol strings turn into variables in a later patch, actually...)