Albert Cohen wrote:
> Unfortunately, the state of the art (more recent that the thesis
> referenced in the original email, see Touati's web page) is limited to
> basic block and software-pipelining scopes, and limited to scheduling.
>
> Compared to the tasks currently managed by reload, it certainly misses a
> whole bunch of instruction selection and immediate operand/address mode
> corner case problems (depending on the target). It also misses global
> scheduling, but extended BB scheduling is not very hard to approximate,
> as well as superblock scheduling.
>
> I'm not at all a knowledgeable person to tell you what to do in the case
> of GCC, but for sure saturation/sufficiency-based approches are not
> sufficient to kill the dragon.
In a brief exchange I had with Michael off-list, we discussed that. I
observed that of the things that reload does,
constraint-satisfaction/insn-variant-selection is its primary purpose, and
spill/reload code generation is something it often does suboptimally (and
secondary reloads even worse). If a clever pass running before reload could
insert explicit spill/reload code at well-chosen places (bearing in mind
class-based register pressure), it could relieve reload of the necessity to
generate its own spill code most of the time, and let it just do what it does
best. So, yes, it doesn't kill the dragon, reload would need to be retained
and would still need the last-resort ability to do all the stuff it does now -
but mostly it wouldn't have to in practice, and a sleeping dragon is still an
improvement on a wide-awake one that's stomping round in a furious bad temper
burning everything in sight.... Reload would definitely generate better code
if it was fed stuff that avoided exercising its weakest points; sounds like a
pre-conditioning pass based on your techniques might work really well.
> If you interested in collaboration on the topic, we are about to start
> extending those approaches to general control-flow, and implementing it
> in a production compiler (not GCC, but a free one, and not LLVM either).
:) I'm not up on advanced compiler theory, I'll have to sit back at this
point and leave it to the collective genii to get on with! (I'll just suggest
that one advantage of implementing things in GCC is that it runs in such a
huge range of environments and targets, it's a good way to expose any new
algorithm to "interesting" problems caused by quirky architectures.)
cheers,
DaveK
