Hi, I have a project where I am creating a language which is very similar to C, but has some extensions. Among the most important are: 1) A new 1-bit data-type 2) Some gates: NOT, AND, etc.. that act on arrays of this 1-bit type. (Think like a hardware description language.) These are like external function calls, which don't have an implementation for now. I don't have a particular target, and would like to translate to the LLVM IR format for now. I want to leverage the power of LLVM SSA transformation/optimization framework. I would like to know your opinion about my approach: 1) I have already added a new type to clang's lexer/parser for my high-level language. Do I need to add a new type to LLVM IR as well? I read some warnings about this being difficult to implement. As far as I understand, there is structural typing in LLVM. Can I just utilize the i1 type? Is the i1 type already used for something, and thus might create a conflict? 2) Can I use LLVM's intrinsic functions for my gates, something like @llvm.NOT(i1 %val)? Would the fact that the implementation of these external functions is not defined, create a problem in translation down to IR? I have used Clang's "built-ins" in the front-end and that seems to do the job at the parser level. Thanks, Ali PS. Just to clarify again, this is not intended as an addition to LLVM's codebase. It's solely for my own purpose. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130203/34a6a917/attachment.html>
> Can I just utilize the i1 type? Is the > i1 type already used for something, and thus might create a conflict?I think you are very confused. LLVM's types are meant to be used to represent *your* program :) They can't be "already used".> 2) Can I use LLVM's intrinsic functions for my gates, something like > @llvm.NOT(i1 %val)? Would the fact that the implementation of these external > functions is not defined, create a problem in translation down to IR? I have > used Clang's "built-ins" in the front-end and that seems to do the job at > the parser level.Again, I think you are confused. Just use the operations that are built into LLVM, such as <http://llvm.org/docs/LangRef.html#bitwise-binary-operations>. One slight point of confusion is that LLVM tries to be minimal so there is no NOT instruction; `NOT X` is represented as `XOR X, -1`. You probably won't need to add an intrinsic unless you are doing something _very_ exotic. -- Sean Silva
Hi Sean,>> Can I just utilize the i1 type? Is the >> i1 type already used for something, and thus might create a conflict? > > I think you are very confused. LLVM's types are meant to be used to > represent *your* program :) They can't be "already used".I am keeping all the types of C, and adding my new types. I thought that, for example, I can't map my new type to i32 because that's used for C integers. That's what I meant by already used. Am I missing something?> >> 2) Can I use LLVM's intrinsic functions for my gates, something like >> @llvm.NOT(i1 %val)? Would the fact that the implementation of these external >> functions is not defined, create a problem in translation down to IR? I have >> used Clang's "built-ins" in the front-end and that seems to do the job at >> the parser level. > > Again, I think you are confused. Just use the operations that are > built into LLVM, such as > <http://llvm.org/docs/LangRef.html#bitwise-binary-operations>. One > slight point of confusion is that LLVM tries to be minimal so there is > no NOT instruction; `NOT X` is represented as `XOR X, -1`. You > probably won't need to add an intrinsic unless you are doing something > _very_ exotic. >That's a good point. However simple binary operations such as XOR are not the only ones I'll be using. I have the Toffoli Gate for example which takes in 3 operands: http://en.wikipedia.org/wiki/Toffoli_gate I guess I can use intrinsics for these things? If I do, can I leave its behavior undefined? I would like it to appear just with the name toffoli in the IR. Thanks, Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130203/e7691633/attachment.html>