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

Craig Topper via llvm-dev llvm-dev at lists.llvm.org
Sun Mar 18 16:43:40 PDT 2018


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/3b2f462e/attachment.html>


More information about the llvm-dev mailing list