Re: [Tinycc-devel] RE :Re: inline functions

[Jared Maddox]

> Date: Wed, 11 Dec 2013 23:27:37 +0000 (GMT)
> From: Rob <address@hidden>
> To: address@hidden
> Subject: Re: [Tinycc-devel] RE :Re:  inline functions
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> Odd, msvc isn't a C99 compiler, didn't expect it to conform.
>

As I best recall, MSVC has always (well, always since C99 was
announced, anyways) had whatever C99 features that it's maintainers
felt like including. The blocker that they've always had with C99
compliance was the need to include features that they DIDN'T feel like
bothering with. Probably best to assume that you'll occasionally run
into random bits of C99 that were added as vendor extensions whenever
dealing with C99.


> Anyway - I know the tcc code somewhat, but I'm not sure about inline
> functions. They're handled as sort-of-macros in some cases, see
> gen_inline_functions().
>
> In short, I'm not sure of the changes and I'm off to bed shortly. I do
> think tcc should remain standard-compliant though, and not imply static
> or extern from just 'inline'. Perhaps we need another flag?
>

A flag won't help, I'm pretty sure this is an inherent limit of TCC.
The lack of stored parse information about functions means that the
information that TCC would need to perform "proper" inlining just
isn't available to the compiler when the inlining must be done,
because it isn't kept anywhere.

There are a few ways to change this:

1) When I finish my current pet project (which is taking longer than I
planned, due to sluggishness on my part) I'm planning to write a
reference-loop-safe smart-pointer system in C, and use it to add a
"parse tree generator" backend to TCC. At that point a parse tree will
be trivially available, and the problem can be dealt with by a
function that receives said parse tree, before passing it on to a
parse tree -to- code stage. If you think that this feature is half-way
time critical, then don't wait for me to do this.

2) We could always cheat by coming up with some custom function format
based upon working "on top" of the caller's stack, and claim that
we've inlined in that way (we might even be able to do a copy-paste
into the correct location on some platforms).

3) We could come up with a "raw function" object format that describes
the calling convention, alignment requirements, and "patch
requirements" required to copy the enclosed inlineable function into
another function. Nesting of inline functions wouldn't work if it
hadn't already been done to the inlineable function, but no big
surprise there. Note that this could technically be done with a copy
of the source code & information about what globals it can see,
instead of with a proper object file.


If such a thing were done, then I would ALSO suggest putting in a
compiler flag to force inlines to be implemented as statics, like they
currently are (or at least should presumably be).