tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] inline assembly and optimization passes


From: Jared Maddox
Subject: Re: [Tinycc-devel] inline assembly and optimization passes
Date: Sat, 21 Sep 2013 00:02:58 -0500

> Date: Fri, 20 Sep 2013 15:50:28 +0200
> From: Thomas Preud'homme <address@hidden>
> To: address@hidden
> Subject: Re: [Tinycc-devel] inline assembly and optimization passes
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Le vendredi 20 septembre 2013 03:08:10 Sylvain BERTRAND a ?crit :
>> Hi,
>>
>> ----
>>
>> I wonder if the internals of tinycc can easily supports basic
>> optimization passes. The idea is not to compete with gcc and its
>> hundred of passes, but my guess is that very few optimization
>> passes would be required to give a significant performance boost
>> to generated code. Just need to select the "right" ones...
>>
>> As a C writer, I have been thinking about the "variable aliasing"
>> pass over a compilation unit. Because a lot of code use many C
>> variables to reference the same actual variable to make code more
>> readable. Then in my ignorant mind I see a lot of wasted
>> registers and stack space and a significant performance loss at a
>> global scale. Wrong?
>
> I'm not familiar with optimization but I would guess it would have a non
> negligeable impact on tcc's performance. If you want basic optimization you
> could try -O1 switch of gcc or clang. Unless the cost of an optimization is
> negligeable, I think adding it to tcc is not a good idea. Many people are
> interested in tcc because of its fast compilation so I would say it's more
> important to keep it fast than to make the generated code better.
>

I recently bought a copy of the "Dragon Book", and according to it,
optimization passes are usually performed on an AST that is created
from a compiler-specific intermediate code: in essence, a specialized
byte code or assembly code that the compiler outputs instead of
directly producing the intended end-product byte code. It shouldn't be
too hard to just add an IC / IL target and let someone do optimization
as a completely different program (probably in a custom
linker-and-optimizer program). I myself have considered adding support
for a VM that could partially support this sort of thing.

If he wants to volunteer to implement such an IC / IL target
(particularly if he also volunteers to provide the assembler with the
ability to understand it), then I say it would be worth considering
any patches that he provided. Certainly though, most optimizations
shouldn't be allowed in TCC itself.


> Date: Fri, 20 Sep 2013 16:42:21 +0200
> From: Sylvain BERTRAND <address@hidden>
> To: address@hidden
> Subject: Re: [Tinycc-devel] inline assembly and optimization passes
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
>> I'm not familiar with optimization but I would guess it would
>> have a non negligeable impact on tcc's performance. If you want
>> basic optimization you could try -O1 switch of gcc or clang.
>> Unless the cost of an optimization is negligeable, I think adding
>> it to tcc is not a good idea. Many people are interested in tcc
>> because of its fast compilation so I would say it's more
>> important to keep it fast than to make the generated code better.
>

> gcc (from 4.8) and clang are dead for me: those are c++ projects
> (you cannot compile gcc 4.8 with tcc even if you wanted to fix
> all required C support for it). I don't like that language for
> Linus T. reasons and more. Let this topic go far away from tinycc
> (trolls/flamewars), please.
>

So the GCC C compiler even depends on C++ features now? I had thought
they were planning to keep the "core" set of compilers as C-based. A
shame.

It probably is worth noting at this point that every once in a while
someone comes along proposing that TCC add a C++ compiler, or at least
some features. Obviously such a thing hasn't been done, but it does
sometimes get proposed. And I at least think that you could get a
pretty good language if you wrote down all of C++'s features, threw
away the standard, and reworked the language to be less messy...



reply via email to

[Prev in Thread] Current Thread [Next in Thread]