Re: add_branch_dependences in sched-rgn.c
On 10/04/14 02:50, Maxim Kuvyrkov wrote: On Apr 9, 2014, at 4:15 AM, Kyrill Tkachov wrote: Hi all, I'm looking at some curious pre-reload scheduling behaviour and I noticed this: At the add_branch_dependences function sched-rgn.c there is a comment that says "branches, calls, uses, clobbers, cc0 setters, and instructions that can throw exceptions" should be scheduled at the end of the basic block. However right below it the code that detects this kind of insns seems to only look for these insns that are directly adjacent to the end of the block (implemented with a while loop that ends as soon as the current insn is not one of the aforementioned). Shouldn't the code look through the whole basic block, gather all of the branches, clobbers etc. and schedule them at the end? Not really. The instruction sequences mentioned in the comment end basic block by definition -- if there is a jump or other "special" sequence, then basic block can't continue beyond that as control may be transffered to something other than the next instruction. Makes sense for things like branches, calls and potential exception-throwers, but how can clobbers and uses change the control flow? Thanks for the help, Kyrill Add_branch_dependencies() makes sure that scheduler does not "accidentally" place something after those "special" sequences thus creating a corrupted basic block. -- Maxim Kuvyrkov www.linaro.org
Code emitted was bloated with no optimisation.
Hi there,
we ported gcc 4.8.1 to our ptivate target and the code is bloated for
the array access as shown below
C file :
int a[10];
int i;
test()
{
a[9] = 10;
a[i] = 20;
}
xgcc -O2 -S test.c
_test:
ld (_a+18), 10 ;a[9] = 10;
ld WA, (_i) ; a[i] = 20;
add WA, WA
add WA, _a
ld HL, WA
ld (HL), 20
ret
.comm _i, 2,2
.comm _a, 20,20
The above generated code looks better when compare to below generated
code with no optimisations
xgcc -S test.c
.comm _a, 20,20
.comm _i, 2,2
.type _test, %function
_test:
sub SP, 4
ld WA, 10
ld (_a+18), WA ; a[9] = 10;
ld WA, (_i) ;code bloated here for a[i]
ld IX, WA
ld BC, 15
cal _C87C_shris
ld IY, WA
ld DE, WA
ld HL, BC
ld WA, IX
add WA, IX
ld DE, WA
ld WA, DE
ld BC, HL
ld HL, 1
ld (SP+2), HL
cmp WA,IX
j lt,_.L2
ld DE, 0
ld (SP+2), DE
.L2:
ld DE, WA
ld HL, BC
ld BC, IY
add BC, IY
ld HL, BC
ld WA, DE
ld BC, HL
ld DE, (SP+2)
add DE, BC
ld BC, DE
ld HL, WA
ld (SP+0), HL
ld WA, 20
ld HL, (SP+0)
ld (a+i), WA
add SP, 4
ret
when you access the array with the constant index i.e a[9] the
generated code was better.
but could not track why the code is bloated for the a[i] access.
Please somebody from the group can share their thoughts and will be
appricate the same.
Thank you
~Umesh
Re: Code emitted was bloated with no optimisation.
On 04/10/2014 04:12 PM, Umesh Kalappa wrote: > Please somebody from the group can share their thoughts and will be > appricate the same. But unoptimized code is expected to be large. Why do you expect otherwise? Andrew.
Re: add_branch_dependences in sched-rgn.c
On Apr 11, 2014, at 2:47 AM, Kyrill Tkachov wrote: > On 10/04/14 02:50, Maxim Kuvyrkov wrote: >> On Apr 9, 2014, at 4:15 AM, Kyrill Tkachov wrote: >> >>> Hi all, >>> >>> I'm looking at some curious pre-reload scheduling behaviour and I noticed >>> this: >>> >>> At the add_branch_dependences function sched-rgn.c there is a comment that >>> says "branches, calls, uses, clobbers, cc0 setters, and instructions that >>> can throw exceptions" should be scheduled at the end of the basic block. >>> >>> However right below it the code that detects this kind of insns seems to >>> only look for these insns that are directly adjacent to the end of the >>> block (implemented with a while loop that ends as soon as the current insn >>> is not one of the aforementioned). >>> >>> Shouldn't the code look through the whole basic block, gather all of the >>> branches, clobbers etc. and schedule them at the end? >>> >> Not really. The instruction sequences mentioned in the comment end basic >> block by definition -- if there is a jump or other "special" sequence, then >> basic block can't continue beyond that as control may be transffered to >> something other than the next instruction. > > Makes sense for things like branches, calls and potential exception-throwers, > but how can clobbers and uses change the control flow? It might be that uses and clobbers are leftovers from before-data-flow infrastructure. You can try removing them from add_branch_dependencies and see what happens. -- Maxim Kuvyrkov www.linaro.org
gcc-4.8-20140410 is now available
Snapshot gcc-4.8-20140410 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140410/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 209284 You'll find: gcc-4.8-20140410.tar.bz2 Complete GCC MD5=7dc7997d063afbb4c3bc6acfe4ec64ba SHA1=4d5996f7be1eec0119419b0464637ba17dc7f2d6 Diffs from 4.8-20140403 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
