This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, dataflow] PR47525 DCE fails to eliminate dead calls to pure functions
> > 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
> >
- References:
- Re: [PATCH, dataflow] PR47525 DCE fails to eliminate dead calls to pure functions
- Re: [PATCH, dataflow] PR47525 DCE fails to eliminate dead calls to pure functions
- Re: [PATCH, dataflow] PR47525 DCE fails to eliminate dead calls to pure functions
- Re: [PATCH, dataflow] PR47525 DCE fails to eliminate dead calls to pure functions
- Re: [PATCH, dataflow] PR47525 DCE fails to eliminate dead calls to pure functions
- Re: [PATCH, dataflow] PR47525 DCE fails to eliminate dead calls to pure functions
- Re: [PATCH, dataflow] PR47525 DCE fails to eliminate dead calls to pure functions
- Re: [PATCH, dataflow] PR47525 DCE fails to eliminate dead calls to pure functions
- Re: [PATCH, dataflow] PR47525 DCE fails to eliminate dead calls to pure functions
- Re: [PATCH, dataflow] PR47525 DCE fails to eliminate dead calls to pure functions