[llvm-dev] Generating a custom opcode from an LLVM intrinsic

Sun Mar 18 20:30:10 PDT 2018

ASM is the text output you want printed in a textual listing of the
assembly. The curly braces you see in some text strings like
"adcx{l}\t{$src, $dst|$dst, $src}" are there to provide different operand
orders for at&t syntax vs intel syntax. Anything after $ matches the name
in the outs/in part of the instruction.

IIC_SSE_PREFETCH is part of the scheduler system to provide
latency/throughput information about the instruction.

PD indicates the instruction should be on the 0x0f two byte opcode map with
a 0x66 prefix.

Most common other values in place of PD
TB - 0x0f opcode map no prefix(0x66, 0xf2, 0xf3) and use of one of those
prefixes should be ignored by the disassembler.
PS - 0x0f opcode map no prefix, but if the disassembler sees a prefix it
should not decode to this instruction. Should be used when there is another
instruction with the same opcode that uses a prefix
PD - 0x0f opcode map with 0x66 prefix
XS - 0x0f opcode map with 0xf3 prefix
XD - 0x0f opcode map with 0xf2 prefix
T8 - 0x0f 0x38 opcode map with no prefix
T8PS - 0x0f 0x38 opcode map version of PS from above
T8PD - 0x0f 0x38 opcode map version of PD from above
T8XS - 0x0f 0x38 opcode version of XS from above
T8XD - 0x0f 0x38 opcode version of XD from above
TA - 0x0f 0x3a opcode map with no prefix
TAPS - 0x0f 0x3a opcode map version of PS from above
TAPD - 0x0f 0x3a opcode map version of PD from above
TAXS - 0x0f 0x3a opcode version of XS from above
TAXD - 0x0f 0x3a opcode version of XD from above

~Craig

On Sun, Mar 18, 2018 at 7:39 PM, Gus Smith <gushenrysmith at gmail.com> wrote:

> Craig, thanks for the quick response. That helps a lot. I had no clue they
> were buried in there, though I guess I should have looked harder -- the hex
> should have given me a clue, perhaps!
>
> For the sake of my own edification (and not taking up too much of your
> time) I will try to generate it myself. I've found the definition of the
> "I" class at line 358 of llvm/lib/Target/X86/X86InstrFormats.td, which
> helps a lot.
>
> Let's assume I want to produce opcode 0x16 (which I'm using because it
> doesn't seem to be implemented in gem5 otherwise, and would simply produce
> a warning). Then my guess is that I should use something like:
> def CACHEADD : I<0x16, FORMAT, (outs), (ins),
>                    ASM, [(int_cache_add)]>, PD;
>
> where FORMAT comes from http://legup.eecg.utoronto.ca/doxygen/
> namespacellvm_1_1X86II.html
> and ASM = ???
> and i deleted  IIC_SSE_PREFETCH (because I'm not sure what this flag
> indicates, but I assume it's not needed).
> I'm not sure what that PD is or if it should stay.
>
> Looking for input on this! Clearly it's not correct as-is, but I feel like
> I'm at least understanding parts of it. Thanks!
>
> For posterity, this page helped a lot, and probably should have been read
> first: https://llvm.org/docs/TableGen/index.html
> In smaller part, this one helped too, but read the above page first:
> https://llvm.org/docs/TableGen/LangRef.html
>
> On Sun, Mar 18, 2018 at 7:43 PM, Craig Topper <craig.topper at gmail.com>
> wrote:
>
>> Here's a couple examples for mapping an intrinsic to an X86 instruction
>> from X86InstrInfo.td. If you look for int_x86_* in any X86Instr*.td you can
>> find others.
>>
>> let Predicates = [HasCLFLUSHOPT], SchedRW = [WriteLoad] in
>> def CLFLUSHOPT : I<0xAE, MRM7m, (outs), (ins i8mem:$src),
>>                    "clflushopt\t$src", [(int_x86_clflushopt addr:$src)],
>>                    IIC_SSE_PREFETCH>, PD;
>>
>> let Predicates = [HasCLWB], SchedRW = [WriteLoad] in
>> def CLWB       : I<0xAE, MRM6m, (outs), (ins i8mem:$src), "clwb\t$src",
>>                    [(int_x86_clwb addr:$src)], IIC_SSE_PREFETCH>, PD;
>>
>> The encoding information for the binary output is buried in these
>> definitions too. If you tell me what opcode you've chosen I can tell you
>> what the right things are to get the binary output.
>>
>>
>> ~Craig
>>
>> On Sun, Mar 18, 2018 at 3:22 PM, Gus Smith via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hello all. LLVM newbie here. If anything seems glaringly wrong with my
>>> use of LLVM, that's probably why.
>>>
>>> Here's what I'm trying to do. I have modified the gem5 simulator to
>>> accept a "new" x86 instruction. I've done this by just reserving the opcode
>>> in gem5's ISA specification, just as all other instructions are specified.
>>>
>>> I'm trying to get an LLVM backend to generate this opcode during code
>>> generation. My current plan is:
>>>
>>>    1. During an LLVM pass, I'll detect a series of instructions which
>>>    can be replaced with this new instruction. (The new instruction is a "cache
>>>    compute" instruction -- in my passes, I replace a series of loads,
>>>    operations, and stores with this single instruction.) This step is complete.
>>>    2. I replace the series of instructions with an intrinsic. I have
>>>    added an intrinsic using the instructions here
>>>    <https://llvm.org/docs/ExtendingLLVM.html#adding-a-new-intrinsic-function>.
>>>    This step is complete.
>>>    3. During code generation, the intrinsic should be converted to this
>>>    reserved opcode. This is where I'm stuck.
>>>
>>> I'm stuck on step 3. I have two main questions that should unblock me:
>>>
>>> Question 1: where is the code that maps from intrinsics to instructions?
>>> The link above states:
>>>
>>> "Add support to the .td file for the target(s) of your choice in
>>> lib/Target/*/*.td. This is usually a matter of adding a pattern to the
>>> .td file that matches the intrinsic, though it may obviously require adding
>>> the instructions you want to generate as well. There are lots of examples
>>> in the PowerPC and X86 backend to follow."
>>>
>>> However, looking through these examples isn't illuminating anything for
>>> me. Any more documentation or high-level explanation on this subject would
>>> be really helpful. I have read something about "lowering" of intrinsics;
>>> not sure if that's relevant.
>>>
>>> Question 2: will I be able to generate this opcode directly from the
>>> intrinsic, or will I have to add the opcode as an LLVM IR instruction and
>>> specify how it gets compiled? I can imagine two options:
>>> option 1: I can define a "translation" from intrinsic straight to an x86
>>> opcode.
>>> option 2: I can define a "translation" (perhaps in a .td file? I think
>>> that's what they're used for) which translates my intrinsic into a new
>>> instruction, and then I can define another translation which will map the
>>> new instruction to my opcode during code gen. If this is the case, I'm not
>>> sure there's any point to having an intrinsic; I should just add a new
>>> instruction instead.
>>>
>>> Hoping someone can help! As you can tell, I'm a little lost...the
>>> documentation for LLVM is great, but it's a little above my level right now
>>> :)
>>>
>>> Gus Smith, PSU
>>>
>>>
>>> _______________________________________________
>>> 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/20180318/65341a78/attachment.html>