[llvm-dev] Porting Automation

Nemanja Ivanovic via llvm-dev llvm-dev at lists.llvm.org
Fri Jul 15 09:41:06 PDT 2016


Hi Martin,

If I'm reading your question correctly, there are really two aspects to
what you're suggesting:
1. A compiler emits a CPU description in some standardized form
2. A compiler that takes such CPU descriptions as input to generate a back
end

As Dean suggested, I believe you can get reasonably good results for number
1. by writing a TblGen-like tool to interpret Target Description files.
Number 2. on the other hand is probably not doable in general. I don't
really think it is feasible to have a generic tool that will simply take a
CPU description as input and emit a functioning back end to hook to a
target-independent compiler.

On Fri, Jul 15, 2016 at 4:46 PM, Dean Michael Berris via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> > On 15 Jul 2016, at 16:33, Martin Vahi via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> >
> > I'm just trying to get an
> > overview of a greater picture, I'm
> > currently not working on any compiler
> > porting or CPU development, but could
> > someone please tell, if there exists in LLVM or
> > some other compiler a feature, where
> > different CPU-vendors offer some standardized
> > XML/JSON/YAML file that describes the CPU's
> > parameters, registers, commands in some formal
> > manner and compilers that support that CPU
> > description format, can just import that CPU-description
> > a bit like bookmarks are imported to web browsers
> > and importing/loading of the formal CPU-description
> > would be all that is needed to port the compiler
> > to that CPU?
> >
> > The file would describe register names, register
> > widths, what command works with what register, etc.
> > Practically the CPU-description file would be
> > written in some domain specific language even if the
> > syntax is XML/JSON/YAML. Again, the idea is that
> > if web browsers are able to configure the GUI
> > according to HTML, then compilers might configure
> > their back-ends according to the CPU-description file.
>
> I'm not aware of any such existing document/resource, but I think it would
> really be a nice resource to have just as a catalogue of what's out there.
> I suspect someone just hasn't done this, or if someone has then that it
> isn't that popular nor accessible.
>
> What I do know is that in LLVM you can look at the existing targets
> described in tablegen files scattered around. It's not exactly XML but I
> think you can probably come up with a generator that takes the tablegen
> inputs and generates an XSD (or equivalent) and an XML document according
> to that generated schema. The tutorials on tablegen should be helpful in
> that regard.
>
> >
> > The CPU description file might even be part of the
> > internal test suite of the CPU-vendor during the
> > development of the CPU. Why the duplication of effort
> > at describing the programming interface specification
> > of the CPU, first at the CPU-vendor side and later
> > at the compiler side?
> > After all, it is CERTAIN that at least SOME COMPILER
> > is needed to make any CPU useful at all, with the
> > exception of some really tiny micro-controllers that
> > might be usable with ASM alone, but even among
> > micro-controllers those are a rarity.
> >
>
> At least for what's in LLVM already, you should be able to do this if
> you're so inclined. :)
>
> > I hope to be the most stupid person on this list,
> > despite hoping that my current letter is smart enough
> > to deserve an answer. :-/
> >
>
> I tried, hopefully that helps (also, note, I'm also a newbie here). :)
>
> Cheers
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160715/57a539fa/attachment.html>


More information about the llvm-dev mailing list