[testsuite, pretty-ipa?] Changes to gcc.dg/ipa tests so that they pass on pretty-ipa

[Jan Hubicka]

> 
> I don't think the two are different in any significant way.  IPA-CP
> does not make any changes in-place, even when it "does not clone" it
> means that is actually clones but the original node is unused and
> discarded after clones materialize.  So I believe that making the
> functions static just avoids a few calls to ipcp_cloning_candidate_p
> and otherwise exercises everything else that calls in a loop would
> have.

Well, the ipa-cost testcases were mostly meant to test that we don't duplicate
too much not that we are able to solve the ipa-cp problem.  I would still
preffer the testcases to be in the more complex form (i.e. involving clonning)
so they test more.  I.e. they test that cost model is sane, that ipa-profile is
not mistakely marking the functions as cold when they are inside loop and that
ipa-cp does its job including duplicatio nas well.

It may make sense to add a testcase that clonning does not happen when function
is discovered to be cold (called once) by ipa-profile and that we still
propagate without duplication for function disovered as cold that both should
work at pretty-ipa.  I can add something along this lines...

Honza
> 
> > The problem is that
> > pretty-ipa is smart enough to work out that function called just once per
> > execution of program is not worthwhile to clone.  We need to modify the
> > testcases by introducing some loops around the calls.
> 
> The proper cost estimates are already checked by ipacost tests
> and I have added a loop to the one that needed adjustments.
> 
> Moreover, we probably do want to test that IPA-CP does propagate
> constants to static functions even if all of their calls are
> considered cold (there may be more than one, IPA-CP will not currently
> clone if all of them are cold).  That would mean duplicating at least
> some of the testcases... and for no real reason, I would say.
> 
> So I still think that making the functions static is the way to go.
> 
> Thanks,
> 
> Martin