<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 3, 2016 at 2:08 PM, Ahmed Bougacha <span dir="ltr"><<a href="mailto:ahmed.bougacha@gmail.com" target="_blank">ahmed.bougacha@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Jun 3, 2016 at 10:11 AM, Kenneth Adam Miller<br>
<<a href="mailto:kennethadammiller@gmail.com">kennethadammiller@gmail.com</a>> wrote:<br>
><br>
><br>
> On Fri, Jun 3, 2016 at 11:53 AM, Ahmed Bougacha <<a href="mailto:ahmed.bougacha@gmail.com">ahmed.bougacha@gmail.com</a>><br>
> wrote:<br>
>><br>
>> -<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>, that list isn't in use anymore.<br>
>><br>
>> On Wed, Jun 1, 2016 at 4:48 PM, Kenneth Adam Miller via llvm-dev<br>
>> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> > Hello all,<br>
>> ><br>
>> > I would like to restrain the compiler that I build on my local box from<br>
>> > picking all but a particular set of opcodes. Is there a way to<br>
>> > accomplish<br>
>> > this in a straightforward way?<br>
>><br>
>> Can you elaborate a bit on what you're really trying to achieve?<br>
><br>
><br>
> Well, I need to construct a corpora. I would like a way to restrain the<br>
> output binaries and trust that the generated binaries use an assembler<br>
> subset that I can work with to be able to more precisely measure the results<br>
> of my work.<br>
<br>
</span>Yeah, depending on how restrictive you want to be, that can be a lot<br>
of work; I don't think you can avoid delving into the various pieces<br>
of ISel.<br>
<div><div class="h5"><br></div></div></blockquote><div><br></div><div>Well, the instruction subset that is being targeted is pretty substantial.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
>><br>
>><br>
>> One starting point could be to introduce new subtarget features, and<br>
>> use them as predicates on the instructions you want (or, probably,<br>
>> those you don't want).  See, e.g., <a href="http://reviews.llvm.org/D18802" rel="noreferrer" target="_blank">http://reviews.llvm.org/D18802</a>.<br>
>><br>
>> Another approach could be to use the (also complex) SelectionDAG<br>
>> legalization machinery to convert the operations you don't want into<br>
>> "legal" ones (that'd be in <target>ISelLowering.cpp, and<br>
>> Legalize*.cpp).<br>
>><br>
>> > I'm pretty sure that there is a list of<br>
>> > opcodes to semantics mappings.<br>
>><br>
>> There isn't, because nothing LLVM does needs it, and, more<br>
>> importantly, because you can't express every ISA in LLVM IR (and vice<br>
>> versa).<br>
>><br>
><br>
> Ok, thank you for your kind reply. I wondered if perhaps I just hadn't found<br>
> what I was looking for, because I know for certain that I looked some time<br>
> ago.<br>
><br>
>><br>
>> > In addition, is there a way to look at an associative mapping of LLVM IR<br>
>> > to<br>
>> > opcode, and/or vice versa?<br>
>><br>
>> There is a mapping of sorts, but, as you saw, it's convoluted:<br>
>><br>
>> - SelectionDAG (optimized instruction selection) has its own set of<br>
>> opcodes. Some are generic and inspired by IR (ISDOpcodes.h), but some<br>
>> are target-specific lower level constructs (<target>ISelLowering.h).<br>
>> Instructions are sometimes associated with these opcodes<br>
>> (ISDOpcodes.h; look for '[(' in the various <target>Instr*.td files)<br>
>><br>
>> - alternatively, FastISel (fast instruction selection) does a more<br>
>> direct mapping from LLVM IR to machine instruction (look for BuildMI<br>
>> calls in <target>FastISel.cpp files)<br>
>><br>
>><br>
>> Shameless plug: I do have an out-of-tree project that tries to infer<br>
>> such a mapping from the various .td files, if you do end up needing it.<br>
><br>
><br>
> Ok, I'm pretty sure that may be the files that I was reading that was so<br>
> convoluted. Yes, I would be happy if anybody were to please point me in the<br>
> direction of any tool that will allow me to know the semantics of an opcode.<br>
> Any IR will do, churning through such convoluted representation is not a<br>
> very effective use of time. I question if the cpu manual wouldn't be a<br>
> better way to go about it.<br>
<br>
</div></div>Here you go:  <a href="https://github.com/repzret/dagger" rel="noreferrer" target="_blank">https://github.com/repzret/dagger</a><br>
Which generates a table (still using those ISD opcodes, and then some)<br>
in, e.g., build/lib/Target/X86/X86GenSema.inc<br></blockquote><div><br></div><div>Thanks! I'll check it out.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Let me know if you need help,<br>
-Ahmed<br>
<div class="HOEnZb"><div class="h5"><br>
>><br>
>><br>
>> -Ahmed<br>
>><br>
>> > _______________________________________________<br>
>> > LLVM Developers mailing list<br>
>> > <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
>> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>