[llvm-dev] Custom assembler subset

[Kenneth Adam Miller via llvm-dev]

On Fri, Jun 3, 2016 at 11:53 AM, Ahmed Bougacha <ahmed.bougacha at gmail.com>
wrote:

> -llvmdev at cs.uiuc.edu, that list isn't in use anymore.
>
> On Wed, Jun 1, 2016 at 4:48 PM, Kenneth Adam Miller via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Hello all,
> >
> > I would like to restrain the compiler that I build on my local box from
> > picking all but a particular set of opcodes. Is there a way to accomplish
> > this in a straightforward way?
>
> Can you elaborate a bit on what you're really trying to achieve?
>

Well, I need to construct a corpora. I would like a way to restrain the
output binaries and trust that the generated binaries use an assembler
subset that I can work with to be able to more precisely measure the
results of my work.


>
> One starting point could be to introduce new subtarget features, and
> use them as predicates on the instructions you want (or, probably,
> those you don't want).  See, e.g., http://reviews.llvm.org/D18802.
>
> Another approach could be to use the (also complex) SelectionDAG
> legalization machinery to convert the operations you don't want into
> "legal" ones (that'd be in <target>ISelLowering.cpp, and
> Legalize*.cpp).
>
> > I'm pretty sure that there is a list of
> > opcodes to semantics mappings.
>
> There isn't, because nothing LLVM does needs it, and, more
> importantly, because you can't express every ISA in LLVM IR (and vice
> versa).
>
>
Ok, thank you for your kind reply. I wondered if perhaps I just hadn't
found what I was looking for, because I know for certain that I looked some
time ago.


> > In addition, is there a way to look at an associative mapping of LLVM IR
> to
> > opcode, and/or vice versa?
>
> There is a mapping of sorts, but, as you saw, it's convoluted:
>
> - SelectionDAG (optimized instruction selection) has its own set of
> opcodes. Some are generic and inspired by IR (ISDOpcodes.h), but some
> are target-specific lower level constructs (<target>ISelLowering.h).
> Instructions are sometimes associated with these opcodes
> (ISDOpcodes.h; look for '[(' in the various <target>Instr*.td files)
>
> - alternatively, FastISel (fast instruction selection) does a more
> direct mapping from LLVM IR to machine instruction (look for BuildMI
> calls in <target>FastISel.cpp files)
>
>
> Shameless plug: I do have an out-of-tree project that tries to infer
> such a mapping from the various .td files, if you do end up needing it.
>

Ok, I'm pretty sure that may be the files that I was reading that was so
convoluted. Yes, I would be happy if anybody were to please point me in the
direction of any tool that will allow me to know the semantics of an
opcode. Any IR will do, churning through such convoluted representation is
not a very effective use of time. I question if the cpu manual wouldn't be
a better way to go about it.


>
> -Ahmed
>
> > _______________________________________________
> > 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/20160603/10963b1c/attachment.html>