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