Re: [PATCH] Remove empty loop with assumed finiteness (PR tree-optimization/89713)

[Feng Xue OS <fxue@os.amperecomputing.com>]

>>
>> IIUC that was slightly different: "This option tells the loop optimizer to
>> assume that loop indices do not overflow, and that loops with nontrivial
>> exit condition are not infinite."
>>
>> The assumption on indices looks unsafe indeed if it applied to unsigned
>> indices in non-empty loops.

> The question is of couse what a "nontrivial exit condition" is.  Indeed
> the general handling of unsigned wrapping was what made the option
> useless in practice.

> But we thoroughly need to specify "nontrivial exit condition", if going
> as far as non-constant exit condition, that is, only do {} while (1) is required
> to be detected as infinite then this breaks down to unsigned wrapping IVs
> not be infinite.  Otherwise it requires the compiler to be able to correctly
> analyze all unsigned IVs which I know we do not at the moment (SCEV
> has limits).

> So - any suggestion as to how define "nontrivial exit condition"?

>>
>> Why exactly are we trying so hard to preserve no-side-effect, infinite
>> loops? What are they good for? Note that reading an atomic or volatile
>> variable counts as a side effect for this purpose. It looks like some kind
>> of busy waiting, but without checking a flag, so it can only be stopped by
>> some external action (say a signal), so if the OS has any notion of sleep
>> for a thread, blocking would be better. Or maybe it is running through a
>> circular list, ensuring that it stays in RAM? Anyway it seems specific
>> enough that that strange code should be the one needing an annotation.

> I guess we preserve them because we have to?

> I suppose we could add a flag that allows us to elide
> loops with no side-effect and non-constant exit condition
> (so only preserve do{}while (1))?

> Not sure where that would fit best though - certainly not
> in niter / IV analysis but in CD-DCE then?

Now finiteness assertion is only used in a very late CD-DCE, which is located after all loop optimizations are done. And we can even place it as late as just before RTL-expansion. This might be safe enough to let hidden infinite loops exposed.

Moreover, in CD-DCE, if a loop contains side-effect statements, w/o finiteness assertion does not trigger loop removal.

Feng