This is about the target specification proposal described in
http://nondot.org/sabre/LLVMNotes/TargetSpec.txt
At the end of the year I spent a while on this, partly as a foot-wetting
exercise for parts of LLVM I wouldn't otherwise look at. I did a partial
implementation; enough to understand most of the issues (I hope) and get
a clear idea of what would need to be done to phase it in. I expect to
have adequate time over the coming months to do the necessary work.
The first open problem comes from two points in TargetSpec.txt:
Some high level design points:
- The new class will live in libsupport and thus cannot use anything
from codegen or other higher level libraries.
and
The biggest source of ugliness here is that we have to have a giant
table of target features (SSE4!) and arch specific CPU names. This is
already running through tblgen and should continue to do that. We can
even extend it to reason about OS's etc.
The problem here is that tblgen depends on Support. I'm looking for
guidance on the right thing to do here, and (depending on the answer)
possibly some suggestions on getting the build systems to do it.
The simplest solution is probably to just break it out into its own library.
– Sean Silva
The simplest solution is probably to just break it out into its own
library.
That is how I prototyped, yes, with a lib/TargetSpec and
libLLVMTargetSpec.
One other point I'd like comment on, before I start submitting code,
is the build process to allow TargetSpec to collect information from .td
files of all enabled processors. I'm not terribly familiar with either
autoconf or cmake, so I'm not sure there isn't a better scheme than what
I've done. The desire is to accumulate tblgen output from the enabled
backends into a single place that the backend-independent TargetSpec.h
can refer to. Briefly, I propose an
include/llvm/Config/TargetSpec.def
generated at configure/cmake time by the same methods as the other *.def
files, containing an #include for each backend:
#include <ARM/GenTargetSpec.inc>
#include <CppBackend/GenTargetSpec.inc>
#include <Hexagon/GenTargetSpec.inc>
... and so on.
One point on which this differs from current backend tblgen output
files is that the base file names lack a prefix; this is because
the prefix, which is currently only used internally to each backend
library, does not appear to be knowable at configuration time --
e.g. PowerPC/PPC*.inc. (Related is that the relations between backends,
configure targets, and 'arch'es seems a bit muddled; in the more distant
future I'd like to make the TargetSpec Arch explicit in tablegen,
adjacent to the cpus and features.)