Adding custom operation intrinsic for ASIP architectures.

Project Infrastructure LLVM Dev List Archives
1

From: Mikael Lepist? <mikael.lepisto@tut.fi>

Hi,

Hi Mikael

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
Instruction-set Processors).

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 :slight_smile: 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
well).

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

Kind regards
Nikolaos Kavvadias

PS: Is your processor a SIX-letter word? Can it be eaten/drunk? :slight_smile:

2

nkavv@physics.auth.gr wrote:

From: Mikael Lepist? <mikael.lepisto@tut.fi>

Hi,
    
Hi Mikael

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
Instruction-set Processors).

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 :slight_smile: for the current/future developer.

I think you want to convert macro-inclusions (that invoke certain custom
instructions through inline assembly) to LLVM parlance.
  

Well.. we don't use native inline assembly (llvm IR and llvm assembly
is enough for us), but yes we like to call custom operations straight
from C code and presentation of those in llvm IR for later use.

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

Basically later on we'll write some analyzes for finding out code
patterns which are used frequently in program. We'll use that
information for generating special operations (and instruction
selector patterns) for the program.

Anyways, we need also need to support manual insertion of custom
operations, for example if we want to implement some IO functionality
for the processor etc.

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

In this phase we always call custom operations straight away from
source code.

Mikael Lepistö