tinycc-devel
[Top][All Lists]
Advanced

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

[Tinycc-devel] How to get DCE (or something similar) [was: inline assemb


From: Vittorio Giovara
Subject: [Tinycc-devel] How to get DCE (or something similar) [was: inline assembly and optimization passes]
Date: Tue, 24 Sep 2013 10:55:46 +0200

On Tue, Sep 24, 2013 at 4:44 AM, Jared Maddox <address@hidden> wrote:
>> Date: Mon, 23 Sep 2013 14:31:04 +0200
>> From: Vittorio Giovara <address@hidden>
>> To: address@hidden
>> Subject: Re: [Tinycc-devel] inline assembly and optimization passes
>> It would be really nice to have some compiler switch (if not
>> integrated) that enable this functionality.
>
> What kind of dead code? If you're talking about getting rid of ifs,
> whiles, etc., that you can theoretically know at compile-time will
> never be used, then they fall into two categories:
> 1) those that are constants entirely within the argument to the
> conditional ( e.g. if( 0 ), and at a higher level if( a / a > 1 ) ),
> and
> 2) those that are constrained to a range of values within the
> conditional that will always evaluate to false, but are not strictly
> constants.
>
> Category 1, and especially it's first sub-case, are relatively easy to
> deal with, and should be possible to optimize out of TCC within the
> current framework. Subcase 2 is a little more complicated, because you
> need to use elimination or similar to determine that one or more
> things are actually just a distraction within the expression, and
> theoretically shouldn't have any effect; however, in the real
> bit-limited world, this can technically have an effect by interfering
> with floating point accuracy calculations, so it should probably be
> placed under a higher-level optimization flag.
>
> Category 2 requires a more in-depth analysis, which is, in turn,
> relevant when inlining functions from other compilation contexts as
> well. Thus, I'd say that both because of it's greater complexity, and
> because of it's utility when operating on the output of other
> compilation stages, treatment for category 2 should be kept separate
> from TCC proper.

Yes, as you got below I meant removing functions such as

if (0)
   some_function();

The "problem" is that many applications use this construct instead of
adding #ifdefs everywhere. So right now if some_function() is
undefined you just get a "tcc: undefined symbol some_function", even
though execution of that code would survive. For what it is worth I'd
just need tcc not to fail from this undefined symbol.

>
>
>> Date: Mon, 23 Sep 2013 17:05:35 +0200
>> From: Vittorio Giovara <address@hidden>
>> To: "Thomas Preud'homme" <address@hidden>
>> Cc: address@hidden
>> Subject: Re: [Tinycc-devel] inline assembly and optimization passes
> If, on the other hand, you're talking about dead code elimination in
> the sense of getting rid of functions that aren't used, then see the
> following. This interplays with getting rid of similar code inside of
> functions, but is easier in some ways.

So, I took a very noob approach and tried the following in tccelf.c:

1. don't abort when you find an undefined symbol (gives FPE at execution)
2. mark every undefined symbol as weak linked (segafaults)
3. hijack every undefined function to a sink function that does
nothing (couldn't fully implement it)

I might have done something wrong with the approach but right now I'm
quite out of ideas (and code knowledge). Any in-depth hint is highly
appreciated.

>
> Try looking here:
> https://lists.nongnu.org/archive/html/tinycc-devel/2012-10/msg00044.html
>
> The gcc compiler & linker flags mentioned there are directly relevant
> to this, and basically describe the relevant operations: each function
> and variable goes into a separate section within the object file (or,
> in the case of TCC, sometimes just in memory), and either all of the
> sections get stored into a library file, or only the ones actually
> used get stored into an object or executable file. So, multi-step
> process, but the end result is definitely useful.
>
> AFTER that gets done you can worry about invoking the optimization
> with a single flag, since those capabilities are just as useful by
> themselves as they are when grouped together.

As first step I'd be happy with compiling some code like the one
above, the optimization of actually removing it might come later on.

>
> Note: I had actually thought that I read somewhere that TCC already
> had this capability, but I didn't see it pop up anywhere when I
> Googled.

Yeah I thought that too, but can't find it anywhere :\

Vittorio



reply via email to

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