[RFA] Some fixes to ipa-pure-const local analysis

[Jan Hubicka]

> > Simple structure constructors are not gimple min invariant (except for
> > setting everything to zero), so is_giple_min_invariant is definitly
> > overly conservative.
> >
> > I am not expert in this area but reading code of C and C++ frontend
> > seems that all offline constructors are those having
> > TYPE_NEEDS_CONSTRUCTING set.
> >   
> Then you should consult an expert to figure out how to upgrade this code.

This is why I sent this patch for review and hope some expert to appear
and tell me :)
> 
> >>     
> >>> 3) chec_rhs_var/check_lhs_var is looking if statement can trap.  This is not
> >>> sufficient because we should check stmt_count_trap_p instead. Still it seems
> >>> wrong.  There is no code in compiler that would make difference in between CONST
> >>> and PURE this way.  Only sane reason for this check I can think of is to avoid
> >>> DCE from eliminating the call causing program to not trap.  This would be handled
> >>> by setting local->looping flag instead, but still since DCE itself is happy to
> >>> eliminate stmt_could_trap_p statements, I think this is all unnecesary.
> >>>
> >>>   
> >>>       
> >> rtl dce will not delete insns that can trap.   if the tree/gimple dce
> >> can, then there may be a problem.  I would assume that the trap testing
> >> is not great since c code generally does not trap.
> >>     
> >
> > gimple_could_trap is correct predicate here.  We assume trapping all
> > floating point operations with flag_trapping_math that default to 1, so
> > having the check here effectivly mean that no FP function can be
> > removable.  Definitly in C compiler is free to remove such operations.
> > We just can't remove throwing instructions with -fnoncall-exceptions for
> > Java, but that is handled elsewhere, so I think the check here just can
> > be skipped.
> >
> >   
> Some check needs to be there.    I am not saying that we got the right
> set of checks but if we are throwing things, we can only mark the
> function pure, we cannot mark it const.

throwing is not trapping.  In C++ you throw via throw() call that will
make funtion unpure.  In Java you can throw via NULL pointer reference
and similar construct and Java does not allow these to be optimized out.
Flag_non_call_exception && gimple_can_throw is correct predicate here. 

Can you give me example where const/pure makes difference here?
I can only think of problem of removing the throw, but both const and
pure functions can be removed.
> >
> > You mean something like:
> > int *p = &static_var
> > return *p;
> >   
> yes, something like this.

Hmm, this is handled at INDIRECT_REF checking.  How much it is different from

int
t(int *a)
{
  return *a;
}

that is also just pure but not const?

this is why I think we are speaking only of code:

int *
t(int a)
{
  return &a
}

that is undefined anyway.

Honza
> 
> > ?
> > Honza
> >