Scheduling x86 dispatch windows

[Joern Rennecke]

Quoting Andi Kleen <andi@firstfloor.org>:

> On Sun, Jun 13, 2010 at 07:14:03AM -0400, Joern Rennecke wrote:
>> Quoting Andi Kleen <andi@firstfloor.org>:
>>> I admit I haven't looked into gas code, but naively it can't
>>> be all that difficult to e.g. run gas as a thread and
>>> pass the text input through some shared memory buffer?
>>
>> If you are generating text anyway, there should be little difference to
>> the existing -pipe option - at least on operating systems that can handle
>> processes efficiently.
>
> Yes but you can't easily pass data back, like accurate instruction lengths.

We were just talking about saving time by reducing the work of the
assembler, which Ian said takes about 3% of the compilation time.
So in that context, -pipe should be similar to text buffer thread
communication.

If you want to make exact length information available to the scheduler,
text buffers are not all that easy to use - the assembly output of the
compiler is so far only done in final, and things like register allocation
(for sched1), machine_dependent_reorg, peepholes, final_{pre_}scan_insn,
assembler dialects, and functional output templates that rely on some data
to be computed by prologue code or similar are in the way of getting a
string suitable for the assembler during scheduling.
And if you have to audit and/or patch every pattern of your port to verify
that it'll work in a different context, you might as well fix the length
information.

An even if you have a suitable text for the assembler, to link the compiler
with the assembler requires to merge to two complex build systems, and
resolve symbol name clash issues.
Using socketpair / fork / exec for the interface would restrict portability
to the new feature to host operating systems that implement these system
calls, but you wouldn't have to worry about having to merge the compiler
with the assembler.
Or if you have a bit more (developer & CPU) time, you can use a client/server
interface with AF_UNIX / AF_INET sockets.  Or you could go for SYSV shared
memory.
All of these Inter Process Communication mechanisms with nice autoconf and
configure option scripting together will likely be only a fraction of the
hassle of trying to merge gcc and gas and to push the patches for that
monster upstream.
For starters, gas and gcc have different maintainers, asynchronous  
release schedules, and reside in different repositories with different  
version
control systems.

Using the opcodes directory directly could be slightly saner, if it
were not for the fact that there are about as many different interfaces as
there are different ports.
Alhough the cgen ports have some things in common, there is always some
port-specific glue.  And there are still plenty of non-cgen ports, too.