[llvm-dev] Custom assembler subset

Fri Jun 3 11:36:34 PDT 2016

On Fri, Jun 3, 2016 at 2:08 PM, Ahmed Bougacha <ahmed.bougacha at gmail.com>
wrote:

> On Fri, Jun 3, 2016 at 10:11 AM, Kenneth Adam Miller
> <kennethadammiller at gmail.com> wrote:
> >
> >
> > 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.
>
> Yeah, depending on how restrictive you want to be, that can be a lot
> of work; I don't think you can avoid delving into the various pieces
> of ISel.
>
>
Well, the instruction subset that is being targeted is pretty substantial.

> >>
> >>
> >> 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.
>
> Here you go:  https://github.com/repzret/dagger
> Which generates a table (still using those ISD opcodes, and then some)
> in, e.g., build/lib/Target/X86/X86GenSema.inc
>

Thanks! I'll check it out.

>
> Let me know if you need help,
> -Ahmed
>
> >>
> >>
> >> -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/934dbbbe/attachment.html>