llvm dev - Jan 2021 - Thoughts on speculatively creating IR and throwing it away if not needed

> Given that this might push the envelop of the pattern a bit, I’d like 
to check if there are any concerns with using this pattern more widely.

Is the idea here to generate instructions which are collectively cheaper 
than their individual costs (due to reuse/combinations)? Or is it a 
matter of not really knowing what instructions will be generated and no?

/Jonas

Hi Jonas,
> On Jan 18, 2021, at 18:01, Jonas Paulsson via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> > Given that this might push the envelop of the pattern a bit, I’d like
to check if there are any concerns with using this pattern more widely.
> 
> Is the idea here to generate instructions which are collectively cheaper
than their individual costs (due to reuse/combinations)? Or is it a matter of
not really knowing what instructions will be generated and no?

This is a great way to frame it.

The motivation is a bit of both. SCEV expansion will try to re-use existing
expressions (including ones inserted by earlier expansion steps), so the overall
cost will be cheaper collectively than when looking at the cost of each
expression individually. There potentially are a number of SCEV expansion
happening (e.g. SCEV assumptions, one for each runtime check bound).

And without traversing the full SCEV expression, we cannot tell which
instructions will be generated. So to estimate the cost, we would have to
traverse the whole expression, just to traverse it again when we generate the
actual code.

And we are also able to directly & accurately compare the cost of the
generated instructions to the computed loop cost, using exactly the same metric.

Cheers,
Florian