Re: [PATCH, dataflow] PR47525 DCE fails to eliminate dead calls to pure functions

[Jan Hubicka <hubicka at ucw dot cz>]

> > I think when the possibility of infinite loops was discussed first time, they was
> > declared to be "runtime side effect"
> 
> Well, I think at least the docs for pure/const should be amended to
> mention dead-code elimination (in case the return value is not used,

Yes. We should probably replace "loop optimization" by "code motion"
since pure/consts can be subject of PRE.

I don't like much defining the meaning of pureness of function by listing
what optimizations are performed. On the other hand it is probably more
practical approach than "proper" definition. I can't think of any other
optimization we do or want to do that can not be seen as consequence of
CSE/DCE/code motion.

> in which case a void function as in the testcase doesn't make much
> sense).  The docs should also mention that the compiler assumes
> a pure / const function always returns normally even when
> noreturn or throw is specified (which both is weird).

DCE on noreturn functions is very undefined thing. We have no idea where to
place the new fallthrough edge.  I would expect normal DCE to not remove such
statement since it is a control flow and control flow statements are not
removed even when they have no side effects.  I am very surprised RTL DCE
manages to take that statement away without ICEing.

Also note that const&pure functions can throw (same way as normal operations
can).

I am not sure if "return normally" is well defined and understandable by user,
but I guess we could write that function must always either "return normally or
by exception handling".  It would be similar to what we already have in
leaf attribute definition:
  Calls to external functions with this attribute must return to the current
  compilation unit only by return or by exception handling.

I can think of function whose body is infinite loop without side effects
except for throwing exception after finitely many iterations.  Such function is
technically noreturn & pure. Still I would preffer to just warn as such flag
combination makes no sense in sane code.  I would also mention in docs
that const/pure functions should not be noreturn or returns_twice since those
flags imply side effects not allowed by definition of const&pure functions.

Honza
> 
> Richard.
> 
> > Honza
> >