> Guide for adding a new IR instruction to the Hermes compiler. Use when the user asks to add, create, or define a new IR instruction (Inst/Instruction) in the Hermes intermediate representation. Covers all required files and the patterns for each.
npx skills add https://github.com/facebook/hermes --skill add-ir-instruction
When adding a new IR instruction, you must touch a specific set of files. This
skill describes each file, the pattern to follow, and important conventions.
doc/IR.md — Documentation (the only place for doc-comments)include/hermes/IR/Instrs.def — Instruction registrationinclude/hermes/IR/Instrs.h — Class definition (NO doc-comments here)include/hermes/IR/IRBuilder.h — Builder declarationlib/IR/IRBuilder.cpp — Builder implementationlib/IR/IRVerifier.cpp — Verification logiclib/Optimizer/Scalar/TypeInference.cpp — Type inference stublib/BCGen/HBC/ISel.cpp — HBC instruction selection (stub or implementation)lib/BCGen/SH/SH.cpp — Static Hermes codegen (stub or implementation)10. lib/BCGen/facebook/Mins/Mins.cpp — Mins codegen (stub or implementation)
11. Tests — At minimum, update or add tests in test/
If the instruction needs lowering (i.e., it does not map directly to a bytecode
opcode), you also need:
12. include/hermes/BCGen/Lowering.h — Lowering pass declaration
13. lib/BCGen/Lowering.cpp — Lowering pass implementation
14. lib/BCGen/HBC/LoweringPipelines.cpp — Register pass in HBC pipeline
15. lib/BCGen/SH/SH.cpp (in lowerModuleIR) — Register pass in SH pipeline
doc/IR.mdThis is the ONLY place to put documentation for the instruction. Do NOT add
doc-comments to Instrs.h.
Add a markdown table entry in the appropriate section:
### MyNewInst
MyNewInst | _
--- | --- |
Description | Brief description of what the instruction does.
Example | `MyNewInst %arg1, %arg2 : type`
Arguments | *%arg1* is ... *%arg2* is ...
Semantics | Describe the semantics, referencing the spec where appropriate.
Effects | Describe side effects (e.g., "May read and write memory.", "May read memory and throw.", "Does not read or write memory.").
Instrs.defAdd a DEF_VALUE entry. Place it near related instructions:
DEF_VALUE(MyNewInst, Instruction)
If it's a subclass of another instruction, use the parent as the second argument.
If it's a terminator, use TERMINATOR instead of DEF_VALUE.
Instrs.hDo NOT add doc-comments to this file. Documentation belongs in doc/IR.md.
Follow this exact pattern:
class MyNewInst : public Instruction {
MyNewInst(const MyNewInst &) = delete;
void operator=(const MyNewInst &) = delete;
public:
enum { Arg1Idx, Arg2Idx };
explicit MyNewInst(Value *arg1, Value *arg2)
: Instruction(ValueKind::MyNewInstKind) {
// Optional assertions on operand types:
// assert(arg2->getType().isSomeType() && "message");
// Set the result type:
setType(Type::createNoType()); // for instructions with no output
// or: setType(Type::createFoo()); for typed instructions
pushOperand(arg1);
pushOperand(arg2);
}
explicit MyNewInst(
const MyNewInst *src,
llvh::ArrayRef<Value *> operands)
: Instruction(src, operands) {}
Value *getArg1() const {
return getOperand(Arg1Idx);
}
Value *getArg2() const {
return getOperand(Arg2Idx);
}
static bool hasOutput() {
return false; // true if the instruction produces a value
}
static bool isTyped() {
return false; // true if the output type is meaningful
}
SideEffect getSideEffectImpl() const {
// Compose side effects. Common patterns:
// return {}; // pure
// return SideEffect{}.setReadHeap(); // reads memory
// return SideEffect{}.setReadHeap().setWriteHeap(); // reads+writes
// return SideEffect{}.setThrow().setReadHeap(); // may throw + read
return SideEffect{}.setThrow().setReadHeap();
}
static bool classof(const Value *V) {
ValueKind kind = V->getKind();
return kind == ValueKind::MyNewInstKind;
}
};
IRBuilder.hMyNewInst *createMyNewInst(Value *arg1, Value *arg2);
IRBuilder.cppMyNewInst *IRBuilder::createMyNewInst(Value *arg1, Value *arg2) {
auto *inst = new MyNewInst(arg1, arg2);
insert(inst);
return inst;
}
IRVerifier.cppAdd a visit method that checks invariants:
bool Verifier::visitMyNewInst(const MyNewInst &Inst) {
AssertIWithMsg(
Inst,
Inst.getArg2()->getType().isSomeType(),
"MyNewInst::Arg2 must be of SomeType");
return true;
}
TypeInference.cppAdd an infer method. For instructions without output, return createNoType():
Type inferMyNewInst(MyNewInst *inst) {
return Type::createNoType();
}
If the instruction is lowered before codegen, add fatal stubs. Otherwise,
implement the actual code generation.
HBC ISel (lib/BCGen/HBC/ISel.cpp):
void HBCISel::generateMyNewInst(MyNewInst *Inst, BasicBlock *next) {
hermes_fatal("MyNewInst should have been lowered.");
}
SH (lib/BCGen/SH/SH.cpp):
void generateMyNewInst(MyNewInst &inst) {
hermes_fatal("MyNewInst should have been lowered");
}
Mins (lib/BCGen/facebook/Mins/Mins.cpp):
Unless asked to, do not implement Mins codegen for new instructions.
Leave it as a stub.
void generateMyNewInst(MyNewInst &inst) {
unimplemented(inst);
}
Declare in Lowering.h:
/// Brief description of what the lowering does.
Pass *createLowerMyNewInst();
Implement in Lowering.cpp:
Pass *hermes::createLowerMyNewInst() {
class ThisPass : public FunctionPass {
public:
explicit ThisPass() : FunctionPass("LowerMyNewInst") {}
bool runOnFunction(Function *F) override {
IRBuilder builder{F};
bool changed = false;
// Collect instructions first to avoid iterator invalidation.
llvh::SmallVector<MyNewInst *, 4> insts;
for (auto &BB : *F) {
for (auto &I : BB) {
if (auto *MNI = llvh::dyn_cast<MyNewInst>(&I))
insts.push_back(MNI);
}
}
for (auto *MNI : insts) {
// Replace MNI with lowered IR...
MNI->eraseFromParent();
changed = true;
}
return changed;
}
};
return new ThisPass();
}
Register in pipelines:
In lib/BCGen/HBC/LoweringPipelines.cpp and in
lib/BCGen/SH/SH.cpp (lowerModuleIR), add PM.addPass(createLowerMyNewInst());
at the appropriate point (before any pass that would need to process instructions
introduced by the lowering).
Add lit tests in the appropriate test/ subdirectory. Use %FileCheck or
%FileCheckOrRegen to verify the IR output. If existing tests cover the
feature, update their expected output to reflect the new instruction.
Which subdirectory to use depends on how the instruction interacts with the
compiler pipeline — not every instruction needs tests in every directory:
test/IRGen/ — When the instruction is generated directly from JavaScriptsource. Tests here verify that IRGen produces the expected IR.
test/Optimizer/ — When the instruction affects or interacts withoptimization passes.
test/BCGen/ — Not used as often, but if this IR instruction is used incombination with new bytecode instructions, then place bytecode gen tests here.
Instrs.h. All documentation goes in doc/IR.md.The class in Instrs.h should have no /// or /** */ comments describing
what the instruction does. Brief inline comments explaining non-obvious
implementation details (like side effects) are fine.
in every file (e.g., private field instructions are grouped together).
FooBarInst) must beconsistent across all files: Instrs.def, Instrs.h, IRBuilder.h/cpp,
IRVerifier.cpp, TypeInference.cpp, and all codegen files.
ValueKind is derived automatically. When you addDEF_VALUE(MyNewInst, Instruction) to Instrs.def, the enum value
ValueKind::MyNewInstKind is generated automatically.
Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).
Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).
React Native and Expo best practices for building performant mobile apps. Use when building React Native components, optimizing list performance, implementing animations, or working with native modules. Triggers on tasks involving React Native, Expo, mobile performance, or native platform APIs.
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
Next.js best practices - file conventions, RSC boundaries, data patterns, async APIs, metadata, error handling, route handlers, image/font optimization, bundling
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification
Take facebook/add-ir-instruction from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.