-finline-functions tuning (Using on ET)

[Kurt Garloff]

On Fri, Aug 31, 2001 at 12:04:05PM +0200, Olaf Petzold wrote:
> > 
> > That's 2.95 again, isn't it? 
> > [2.95.3 code deleted].
> Damn, the copy&paste devel....
> 
> Today, once more.....

OK, lookign forward for the results.

> > Could you check how far you have to increase the inline-limit with 3.0.1 and
> > patch v3, please, to get acceptable code? (The gcc-inline-func-acct-v1.diff
> > is irrelevant in your case, AFAICT, but should of course also not do any
> > harm. It just throttles inlining for -finline-functions selected functions
> > a bit more than for inline declared ones.)
> Yes.
> 
> BTW, on hpux, the cc knows the option +Onolimit. Maybee we can adapt this like
> -fno-limits for gcc/g++ ???

-finline-limit-10000 does pretty much the same.

> > I guess, the Blitz code expands to a number of statements > 1 again and
> > again and in the end we end up lowering the limit because we think we've
> > been doing too much inlining. In the end the code collapses to only very 
> > few assembly instructions.
> Yes, the idea is to use the templates to evaluate at compile time recursive. At
> end, we have a kind of loop unrolling using templates, see
> < http://extreme.indiana.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html >.
> A small compileable example is on the top. This shows the principle in short.

Sure, Expression Templates are a powerful technique. Provided the compiler
handles them well.
My question was more how many expression it causes in the G++ parse tree.

Regards,
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7j3AZxmLh6hyYd04RAjkwAKC4FCpCIG3OEshtf8yTK2HGyWc3mgCgxx8i
MRboZ0RMUEXDzL4showLiFo=
=iRUI
-----END PGP SIGNATURE-----