This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Regarding delayed branches and CFGs


hi,
	On a target that supports delayed branches, i have the following code
generated by gcc-3.4.4:

	Before dbr_schedule:
	~~~~~~~~~~~~~~~~~~~
<snip>
1-	label1:

2-	cmp r0,100
3-	branch.eq label2

	.......
4-	move r1, 0
	.......

5-	label2:
	
6-	cmp r1, 0
7-	branch.eq label1
</snip>

	After dbr_schedule:
	~~~~~~~~~~~~~~~~~~
<snip>
1-	label1:

2-	cmp r0,100
3-	branch.eq.delay label3
6-	cmp r1, 0

	.......
4-	move r1, 0
	.......
6-	cmp r1, 0

8-	label3:
7-	branch.eq label1
</snip>
	Thus the cmp instruction is moved to the branch's(3) delay slot, and
the branch is redirected to a new label(8) to avoid redundant
comparison. 

	Now, the problem is that, in absence of a cfg based optimization after
the delayed branch, i end up with a pair of useless move-cmp
instructions (4,6) in the same basic block. I saw a thread on the list,
discussing why cfg build cannot be repeated after the delayed branch
scheduler has been run. So, what would be the best approach to handle
this situation? 

Thanx in advance for any suggestions/hints

regards
saurabh



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]