Re: Fix testsuite for inlining

[Jan Hubicka <jh at suse dot cz>]

> On Tue, Jan 21, 2003 at 10:59:52PM +0100, Jan Hubicka wrote:
> > At the moment decision whether builtin will be fully applied is decided
> > on expansion time while inlining is done earlier.  Even with AST this
> > can be relatively dificult as the fact on whether memcpy will be inlined
> > depends on machine description decision...  Any ideas how to get this
> > easilly?
> 
> Not off the top of my head.  We can make good guesses based on 
> sizes and the relevant macros.  If we guess wrong, we just do
> the out of line call.  The result is still correct.

There is still problem that we would have to move all the decisions out
of the expanders themselves (or ask the expanders).  We have no macro
saying whether strmov expander will pass.

I quite like the idea, so I would want to work on it.  At least I can
make the DECLs generated for the parsed functions to have BUILT_IN set
so we will do the fold_builtin transformations.  That way I can have
floor and floorf inlines and I still will get the floor->floorf
optimization (in case it will be accepted).

However I would like to not do it at once with the unit-at-time and math
bultins little projects.  Would you agree on saying at the current
choice (with noinline bit) and planing this for later?
(I am already nervous about these enought :)

It can definitly be best done on AST level - for instance memcpy builtin
can be folded into series of moves for small blocks and so on.

Honza
> 
> 
> r~