Re: GSoC ideas: sc frontend, multi output compilation, constant path swap runtime optimization

[Ian Lance Taylor <iant at google dot com>]

Tomasz Borowik <timon37@lavabit.com> writes:

> The most beneficial task (for me) would be to just bring the front-end
> I've already written up to mainline quality (though not necessarily
> inclusion), and in the process update some of the documentation or
> maybe even cleanup some gcc code.

I have nothing against new languages, but adding a new frontend doesn't
help GCC very much, at least not directly.  We are always interested in
cleaning up code if you want to propose a project in that area.


> A more middle-back-end task is that I see a need for a certain fairly simple kind of self-modifying code.
> Basically a lot of applications have lots of configuration of their behavior that doesn't get changed through most of run-time, yet there are lots of branches, variable references and pointer dereferences associated with it.
> It should be possible to create something like a global variable that can be read like one (from the programmers perspective) but it gets inlined everywhere like a constant, and a function for changing it's value is generated that changes that value at every point in the output binary.
> Now unfortunately that would still leave a lot of branches in the code so something a bit more complex would be nice, like leaving enough space for either the then or else block, but putting only one in and padding with nops or a jump.
> This isn't really smc very much imo, something more like templating binary code... or template based jit compilation, or let's call it something like "constant path swapping";p
> Either way the benefit is getting a lot of branches, de/references, etc. out of the hot-path, at the cost of significantly slowing down the cold path (assuming people use it for what it's meant for).
> If a given backend does not support the feature it just outputs normal code. There is probably a few more aspects/possibilities to this I'm just loosely throwing it up for comment atm.
> I probably haven't given enough thought to this since I don't have a good idea of the issues associated. Definitely lto would break this but if you ask me lto is a bit misguided as the previously mentioned idea coupled with the way sc and its editor is designed makes it obsolete (unless I'm misunderstanding something).

That is a little vague but it seems that something promising might come
out of it.

Ian