Currently, Clang Driver library is designed around Actions/Tools which are assumed to be external tools and invoked with ExecuteAndWait.
Is there a way to get benefits of driver library integration, but in-process and without forking multiple processes? In other words, compile from source to final executable without fork? If no, how hard would it be to change driver library to make possible to do that?
Thanks
Nikolay
in-process and without forking multiple processes
First off: if your goal is to speed up your builds, I don't think eliminating
fork() overhead is a promising place to start. In the measurements I've done,
the time spent in fork() during a build of `llvm-as' is a tiny, tiny fraction
of one percent.
You can measure this overhead for yourself using dtruss/strace. I suspect that
it's so low because modern OS's use copy-on-write to set up address spaces for
child processes.
compile from source to final executable without fork
If fork() performance overhead is really a problem, or you'd prefer a
non-forking design, I can think of two options.
You could turn the tools in your toolchain into long-lived servers, or you
could (as you mentioned) call into a tool library instead of calling
ExecuteAndWait.
One *advantage* of a fork-based pipeline is that tools never need to clean up
after themselves. E.g, when we fork off a `clang -cc1' instance, we pass it
`-disable-free'. This is a significant time savings (2-3% on average while
building llvm tools). This same performance advantage is available to the
linker, dsymutil, etc.
best,
vedant
To follow-up on this: I don't think it's very hard to do this, but on top of a
possible performance disadvantage, you lose the benefits of process isolation
and the driver's crash reporting mechanism.
vedant