Re: [Tinycc-devel] How to optimize compiling sizeof const?

[Jared Maddox]

> Date: Tue, 29 Jul 2014 19:11:24 +0800
> From: "YX Hao" <address@hidden>
> To: <address@hidden>
> Subject: [Tinycc-devel] How to optimize compiling sizeof const?
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="utf-8"
>
> Hi there,
>
> We know that tcc generates bigger binary file than gcc for non-small
> projects. But I'm not meaning the optimization options.
>
> Here I find the titled issue when I compile an html5 library (Google's
> "gumbo"). In the compiled object file and linked binary file, that of tcc
> you can find the string to be calculated size of is stored, and you will see
> it will not be used with a debugger, while gcc generates clean file with
> smaller size. The attached file is a piece of code for testing.
>

Just to be certain that I'm understanding correctly, you're talking
about something like this:

size_t size_size()
{
  return( sizeof( "sizeof" ) );
}
void arg_size( void (*func)( const char* ) )
{
  if( func )
  {
    ( *func )( "sizeof" );
  }
}

And the behavior in question is that TWO copies of "sizeof" are
included in the resulting object file, correct? This is specifically a
"flex" area in the C standard: strings can be stored uniquely, or
duplicates can be merged for reduced file size. GCC and MSVC do some
extra processing that merges duplicate strings, but TCC doesn't. This
also needs to happen in two places: compile-stage, and link-stage
(though it's the same operation in both cases, so there should be some
common routing point that'll do the trick... I hope).

One of the technical details of how we'd need to do it is that we'd
need to record where a lot of pointers actually are, so that we can go
through later and patch them. Doing it in this particular way would
also allow this to be optional (if disabled, then it could either be
rendered a no-op via tcc compile switch, or an automatic jump-return
via tcc runtime switch), presumably being routed through some other
program (or another mode of TCC). An extended version could actually
be a useful tool for mobi's object-oriented extension, since
redirecting one type of pointer is much like redirecting another type
of pointer.