Re: [Tinycc-devel] Implementing gcc intrinsics

[Vladimir Vissoultchev]

> There is no optimizer that could benefit from inlining, the only
> thing saved would be a call and return, which is a silly optimization.

Unless the body of the function is single __asm__ instruction for instance.

I was thinking about a simple C subset parser that produces AST of the
inline if sucessful. This will leave out recursive functions or anything
more "complex" in general for current impl and be able to inject back
name-mangled C source from the (simple) AST. The trouble starts with local
variables when the inline function is used in an expression but probably
doable in few simple cases. I'm currently research peg/leg
(http://piumarta.com/software/peg/) for simple C parser for inlines.

cheers,
</wqw>

-----Original Message-----
From: Tinycc-devel [mailto:address@hidden
On Behalf Of Michael Matz
Sent: Thursday, April 14, 2016 3:58 PM
To: address@hidden
Subject: Re: [Tinycc-devel] Implementing gcc intrinsics

Hi,

On Wed, 13 Apr 2016, Sergey Korshunoff wrote:

> > I can see that for inlines there is a separate `InlineFunc` struct 
> > that keeps function body until end of generation when in 
> > `gen_inline_functions` only the referenced inlines are generated as 
> > regular functions.
> 
> Then we can search if a function to call is inline function and if so, 
> parse this function body in the form of the {( )} block. A compiler 
> switch can be used to keep old bejavior

You will find that this will not work very well.  Parameter passing is one
problem, scoping another and recursive calls another.  Parsing as ({}) block
doesn't deactive the outer variables, so what should be a compile error
might turn into silently accepting wrong code, or into accessing a local
instead of a global variable.  Functions can call themself recursively,
parsing them as ({}) block that's impossible to implement.

Also: for tcc inlining makes no sense whatsoever.  There is no optimizer
that could benefit from inlining, the only thing saved would be a call and
return, which is a silly optimization.


Ciao,
Michael.

_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel