llvm dev - Aug 2007 - [LLVMdev] Adding custom operation intrinsic for ASIP architectures.

> From: Mikael Lepist? <mikael.lepisto at 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 :) 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? ^_^

nkavv at physics.auth.gr wrote:
>> From: Mikael Lepist? <mikael.lepisto at 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 :) 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ö