This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> On Mon, Jan 31, 2011 at 1:50 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
> >> Hmm, actually we have RTL_LOOPING_CONST_OR_PURE_CALL_P, so I see no problem.
> >> I will try to look into the thread more to figure out what it is all about
> >
> > OK, so I think that Peter's patch is fine. ?The testcase attached to
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47525
> > is indeed nonsential. ?I think noreturn flag there is needed only to avoid
> > GIMPLE optimizers to optimize the function away earlier. ?With lack of unit
> > testing, we might try to come with testcase where GIMPLE optimizers miss the
> > transofrmation for other reason.
> >
> > We might also add sanity checks into c-common.c to warn on such conflicting
> > combinations of attributes, like pure/const & noreturn.
> 
> Well, 1) an endless loop isn't a side-effect, 2) nor is not returning, 3) if

Well, if you define not returning as side effect than docs become less clear
(Looping pure function can also i.e. terminate the program and do other things.
Only what we ensure is that after returning, the memory is not modified)

Docs says:

  Many functions have no effects except the return value and their
  return value depends only on the parameters and/or global variables.
  
  Such a function can be subject
  to common subexpression elimination and loop optimization just as an
  arithmetic operator would be.  These functions should be declared
  with the attribute @code{pure}.  

It does not explicitely mention DCE, tought it is implicit in CSE to be useful.
Nothing of that makes sense on noreturn functions.

> they were, pure + noreturn would be non-sensical - in which case we
> can parse it as looping-const-or-pure (please).  From just looking at

I don't think silently adding looping flag in some cases (such as combination
with noreturn) is sound design and would just confuse users.
Nor we want to flip the default and declare all pure/const functions to be looping
since that would defeat purpose of the flag.

We can warn + drop the flag for sure, but I would not accept noreturn pures as
valid and try to behave sanely here.

Honza

> the testcase (w/o bodies for the fns) it looks bogus to DCE the noreturn
> call.
> 
> Richard.
> 
> > Honza
> >>
> >> Honza
> >>
> >> > looping pure/consts and rely on GIMPLE land to do enough optimization here.
> >> > (this is probably something we would want to revisit later, since pure flag
> >> > is useful for scheduling)
> >> >
> >> > Honza
> >


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]