From: Mikael Lepist? <firstname.lastname@example.org>
I was talking with aKor in #llvm how we could implement custom operation
support for our ASIP architecture. We came into solution that the best
way would be to write new custom operation intrinsic and optimization
pass for raising certain type of function calls to those intrinsics
(similar to raising mallocs).
I'm quite related to this field, both from the compiler (software development
tools) and (micro)architecture point of view (mostly the latter). My Ph.D.
research involves design methodologies for ASIPs (Application-Specific
First of all, i follow rather loosely the developments on LLVM. It really seems
that LLVM grows to a production-quality compiler with much more modern
internals (to the other compiler for the current/future developer.
I think you want to convert macro-inclusions (that invoke certain custom
instructions through inline assembly) to LLVM parlance.
Let's study this more closely.
Basically our custom operation are like calls, with operand name and
multiple inputs and outputs. e.g. C code:
__llvm__custom_op_add(a,b,c) would be raised to customop add(i32 %tmp1,
i32 %tmp24 , i32 %tmp25). Those "__llvm__custom_op_" prefixed function
will not have function body, but pure declarations in C code level.
What is the mechanism to first insert the __llvm__custom_op IR operations? Are
these automatically decided by the code selector? Then, your code selector
should be able to work on DAGs (at least, and ideally to cyclic graphs as
But, oh, i think you mean that you manually inserted the custom operation calls,
since you refer to C code. If it has not been done manually, then there is
something more intruiging and complex, probably involving source-to-source
transformations, procedural abstraction from the IR-level, and possibly some
rewriting (for auto-generated rules by your custom instruction generator) as
PS: Is your processor a SIX-letter word? Can it be eaten/drunk?