llvm dev - Feb 2013 - [LLVMdev] TargetSpec

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.

-- 
Kevin Schoedel kevin.p.schoedel at intel.com +1-519-772-2580
SSG-DPD-ECDL-DMP - Intel Dynamic Mobility and Parallelism

The simplest solution is probably to just break it out into its own library.

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130213/9ab171c0/attachment.html>

> 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.)

-- 
Kevin Schoedel, Software Developer, Intel of Canada