thr3ads.net - llvm dev - [LLVMdev] Are there implicit rules or conventions for an llvm frontend to generate llvm IR? [Oct 2013]

If this information is useful, please help other people find it:
Share via:

Hongxu Chen

2013-Oct-10 15:43 UTC

[LLVMdev] Are there implicit rules or conventions for an llvm frontend to generate llvm IR?

Hi, this question might be a bit silly: apart from the language
reference(http://llvm.org/docs/LangRef.html#switch-instruction) page, are
there additional rules for a regular llvm frontend to generate llvm IRs?

There are a few cases that I got from clang/llvm-gcc/dragonegg when
compiling *C* source code into llvm IR:

1. It seems that there is ONLY ONE ReturnInst(and NO InvokeInst) for such
llvm IR; is it legal to add other *ReturnInst*s when transforming?

2. Is it possible for a frontend to generate a function whose CFG is
something like:

            bb0
       /           \
     bb1          bb2
   /      \       /      \
bb3         bb4        bb5
   \           |          /
     \         |        /
       \       |      /
              bb6

(In this case, if I understand correctly, bb4 is control dependent on both
bb1 and bb2.)
I think it at least possible in theory, and there is a simple case:

int foo(int i) {
  if (i < 0) {
    if (i % 2 == 0) {
      i += 1;
    } else {
      i += 2;
    }
  } else {
    if (i % 2 == 0) {
      i += 1;
    } else {
      i += 2;
    }
  }
return 0;
}

However none of the frontends I used generate the basicblocks like
that(there is always one or more basicblocks generated) /without any
optimizations/. So is there any implicit rules for these frontends?

And can I rely on these cases when I ONLY deal with C source code?

Thanks!



--
View this message in context:
http://llvm.1065342.n5.nabble.com/Are-there-implicit-rules-or-conventions-for-an-llvm-frontend-to-generate-llvm-IR-tp61938.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.

John Criswell

2013-Oct-10 16:06 UTC

head link

[LLVMdev] Are there implicit rules or conventions for an llvm frontend to generate llvm IR?

On 10/10/13 10:43 AM, Hongxu Chen wrote:> Hi, this question might be a bit silly: apart from the language
> reference(http://llvm.org/docs/LangRef.html#switch-instruction) page, are
> there additional rules for a regular llvm frontend to generate llvm IRs?
>
> There are a few cases that I got from clang/llvm-gcc/dragonegg when
> compiling *C* source code into llvm IR:
>
> 1. It seems that there is ONLY ONE ReturnInst(and NO InvokeInst) for such
> llvm IR; is it legal to add other *ReturnInst*s when transforming?
An LLVM function can have multiple ReturnInsts as long as each one 
terminates a basic block.  There is a transform (UnifyExitNodes, IIRC) 
that will take a function with multiple ReturnInsts and create one with 
a single ReturnInst.  Having a single ReturnInst (exit node) simplifies 
other analyses.
>
> 2. Is it possible for a frontend to generate a function whose CFG is
> something like:
>
>              bb0
>         /           \
>       bb1          bb2
>     /      \       /      \
> bb3         bb4        bb5
>     \           |          /
>       \         |        /
>         \       |      /
>                bb6
>
> (In this case, if I understand correctly, bb4 is control dependent on both
> bb1 and bb2.)
> I think it at least possible in theory, and there is a simple case:
Yes, that looks fine to me.  One of the LLVM passes might optimize that 
CFG or put it into some canonical form, but that CFG looks fine to me.

-- John T.
>
> int foo(int i) {
>    if (i < 0) {
>      if (i % 2 == 0) {
>        i += 1;
>      } else {
>        i += 2;
>      }
>    } else {
>      if (i % 2 == 0) {
>        i += 1;
>      } else {
>        i += 2;
>      }
>    }
> return 0;
> }
>
> However none of the frontends I used generate the basicblocks like
> that(there is always one or more basicblocks generated) /without any
> optimizations/. So is there any implicit rules for these frontends?
>
> And can I rely on these cases when I ONLY deal with C source code?
>
> Thanks!
>
>
>
> --
> View this message in context:
http://llvm.1065342.n5.nabble.com/Are-there-implicit-rules-or-conventions-for-an-llvm-frontend-to-generate-llvm-IR-tp61938.html
> Sent from the LLVM - Dev mailing list archive at Nabble.com.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Hongxu Chen

2013-Oct-10 16:41 UTC

head link

[LLVMdev] Are there implicit rules or conventions for an llvm frontend to generate llvm IR?

On Fri, Oct 11, 2013 at 12:06 AM, John Criswell <criswell at
illinois.edu>wrote:
> On 10/10/13 10:43 AM, Hongxu Chen wrote:
>
>> Hi, this question might be a bit silly: apart from the language
>>
reference(http://llvm.org/**docs/LangRef.html#switch-**instruction<http://llvm.org/docs/LangRef.html#switch-instruction>)
>> page, are
>> there additional rules for a regular llvm frontend to generate llvm
IRs?
>>
>> There are a few cases that I got from clang/llvm-gcc/dragonegg when
>> compiling *C* source code into llvm IR:
>>
>>
>> 1. It seems that there is ONLY ONE ReturnInst(and NO InvokeInst) for
such
>> llvm IR; is it legal to add other *ReturnInst*s when transforming?
>>
>
> An LLVM function can have multiple ReturnInsts as long as each one
> terminates a basic block.  There is a transform (UnifyExitNodes, IIRC) that
> will take a function with multiple ReturnInsts and create one with a single
> ReturnInst.  Having a single ReturnInst (exit node) simplifies other
> analyses.
>
> Thanks so much, John; especially for pointing out 'UnifyExitNodes'
pass!
>
>
>> 2. Is it possible for a frontend to generate a function whose CFG is
>> something like:
>>
>>              bb0
>>         /           \
>>       bb1          bb2
>>     /      \       /      \
>> bb3         bb4        bb5
>>     \           |          /
>>       \         |        /
>>         \       |      /
>>                bb6
>>
>> (In this case, if I understand correctly, bb4 is control dependent on
both
>> bb1 and bb2.)
>> I think it at least possible in theory, and there is a simple case:
>>
>
> Yes, that looks fine to me.  One of the LLVM passes might optimize that
> CFG or put it into some canonical form, but that CFG looks fine to me.
>
> -- John T.
>
Got it!

And can I say : as long as it is not explicitly in llvm language reference,
there are generally no restrictions for frontends/transformations to
generate IR(of course, they pass the verifier)?

>
>
>> int foo(int i) {
>>    if (i < 0) {
>>      if (i % 2 == 0) {
>>        i += 1;
>>      } else {
>>        i += 2;
>>      }
>>    } else {
>>      if (i % 2 == 0) {
>>        i += 1;
>>      } else {
>>        i += 2;
>>      }
>>    }
>> return 0;
>> }
>>
>> However none of the frontends I used generate the basicblocks like
>> that(there is always one or more basicblocks generated) /without any
>> optimizations/. So is there any implicit rules for these frontends?
>>
>>
>> And can I rely on these cases when I ONLY deal with C source code?
>>
>> Thanks!
>>
>>
>>
>> --
>> View this message in context: http://llvm.1065342.n5.nabble.**
>> com/Are-there-implicit-rules-**or-conventions-for-an-llvm-**
>>
frontend-to-generate-llvm-IR-**tp61938.html<http://llvm.1065342.n5.nabble.com/Are-there-implicit-rules-or-conventions-for-an-llvm-frontend-to-generate-llvm-IR-tp61938.html>
>> Sent from the LLVM - Dev mailing list archive at Nabble.com.
>> ______________________________**_________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>
http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>>
>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131011/ce6b0acd/attachment.html>

Maybe Matching Threads

Search for more maybe matching threads

llvm dev - Oct 2013 - [LLVMdev] Are there implicit rules or conventions for an llvm frontend to generate llvm IR?

[LLVMdev] Are there implicit rules or conventions for an llvm frontend to generate llvm IR?

[LLVMdev] Are there implicit rules or conventions for an llvm frontend to generate llvm IR?

[LLVMdev] Are there implicit rules or conventions for an llvm frontend to generate llvm IR?

Maybe Matching Threads