Re: Basic blocks and compilers

"Stephen Clarke" <stephen.clarke@earthling.net>
9 Jan 2006 23:55:43 -0500

          From comp.compilers

Related articles
Basic blocks and compilers plfriko@yahoo.de (Christian Christmann) (2006-01-07)
Re: Basic blocks and compilers gneuner2@comcast.net (George Neuner) (2006-01-09)
Re: Basic blocks and compilers FireMeteor.Guo@gmail.com (FireMeteor.Guo@gmail.com) (2006-01-09)
Re: Basic blocks and compilers momchil.velikov@gmail.com (2006-01-09)
Re: Basic blocks and compilers DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-01-09)
Re: Basic blocks and compilers bonzini@gnu.org (Paolo Bonzini) (2006-01-09)
Re: Basic blocks and compilers kenrose@tfb.com (Ken Rose) (2006-01-09)
Re: Basic blocks and compilers stephen.clarke@earthling.net (Stephen Clarke) (2006-01-09)
Re: Basic blocks and compilers lars@bearnip.com (2006-01-09)
| List of all articles for this month |

From: "Stephen Clarke" <stephen.clarke@earthling.net>
Newsgroups: comp.compilers
Date: 9 Jan 2006 23:55:43 -0500
Organization: Compilers Central
References: 06-01-009
Keywords: analysis

"Christian Christmann" <plfriko@yahoo.de> wrote


> I'm using the tricore-gcc v2.8.1 to generate code for my Infineon
> TriCore DSP. Analyzing the generated code (compiled with -O0), I
> noticed a strange behavior of the compiler. (My questions do not
> concern a specific processor but more the theory behind the assembly
> language.)
>
> Here is the code for a simple C function "loopfunc" that is
> called from the main function (not included):
>
> .file "for.c"
> # Generated by gcc 2.8.1 for TRICORE (generic)
> gcc2_compiled.:
> __gnu_compiled_c:
> .section .text
> .align 1
> .global loopfunc
> .type loopfunc,@function
> loopfunc:
> # arg_overflow_area = 0, pretend = 0
> # frame_size = 12, outgoing_args_size = 0
> # f_size = 16, frame_pointer_needed = 0
> # pool_size = 0
> sub.a %SP, 16 # allocate space for locals
> st.w [%a10] 12, %d4
> mov %d1, 0
> st.w [%a10] 8, %d1
> .L2:
> ld.w %d15, [%a10] 8
> ld.w %d0, [%a10] 12
> jlt %d15, %d0, .L5
> j .L3
> .L5:
> ld.w %d15, [%a10] 4
> add %d0, %d15, 1
> st.w [%a10] 4, %d0
> .L4:
> ld.w %d15, [%a10] 8
> add %d0, %d15, 1
> st.w [%a10] 8, %d0
> j .L2
> .L3:
> ld.w %d15, [%a10] 4
> mov %d2, %d15
> j .L1
> .L1:
> ret
> .align 1
> .global main
> .type main,@function
>
> I don't understand why the compiler
> 1) is not spliting basic block .L2 into two blocks where
> the second block just contains the instruction "j .L3".
> I though that each re-direction of the control flow imposes the
> creation of a new basic block (like .L4 and .L3). The instuction
> "jlt %d15, %d0, .L5" can possibly direct the program flow to .L5 and
> thus, in my opinion, the basic block should end here.


You are assuming that each basic block begins with a label,
but that's not necessary: for a BB that is only
reached by fall-through from the preceding block, there is no need to
give it a label at all. So even though it's a distinct BB,
it will not have a label in the final assembly output.


To see the real partitioning of the the code into BBs that
gcc has used, ou need to dump the RTL.


> 2) splits block .L5 and .L4? There are no
> calls to label .L4, so, according to my understanding, all instructions
> of blocks .L5 and .L4 should be held in one block.


BBs do not necessarily have to be maximal.
Compiling at -O0, I would not assume that gcc form
maximal basic blocks.
Also, as the previous point, you should not assume
that the labels in the assembly output actually show the BB
partioning that the compiler has used. To see that you should dump
the RTL.


Steve.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.