On Mon, May 20, 2019 at 10:27 AM Feng Xue OS
<f...@os.amperecomputing.com> wrote:
>
>
> >>
> >> 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.
Is that so? The early pipeline contains a CD-DCE pass as well. Note we also
have pure/const discovery affected by this.
> Moreover, in CD-DCE, if a loop contains side-effect statements, w/o
> finiteness assertion does not trigger loop removal.
That's of course true.
Now we still need to define "non-trivial exit condition" and a way to
actually test for that.
Richard.
> Feng
>
