ARM: allow factorization of constants into addressing insns when optimizing for space

Richard Earnshaw rearnsha@arm.com
Wed Oct 29 14:52:00 GMT 2003


>  > Granted, 0.8% reduction isn't that big either, but just for the sake of
>  > arguing this is twice as significant.  ;-)
> 
> It seems that the effect of the patch heavily depends on the type of the code. 
> Therefore I think that judging based on either of the test beds is 
> inappropriate; the same GCC will be used for compiling linux and applications as 
> well!
> 
> I suspect that even in vmlinux.2 there were objects for which the code size was 
> increased. In the CSiBE benchmark, out of the total 262 object files the patch 
> benefited only in 6 cases (5.5% of the total testbed size), and in 87 cases (51% 
> of the testbed size) the code size increased (other object sizes were not 
> affected). The benefit from these 6 cases was only 0.07%. Therefore the overall 
> 0.4% code size increase.
> 

In an attempt to try and resolve this issue, I tried building gcc with -Os 
for the two different configurations.  Again, the results are not entierly 
conclusive.

Of the 212 files compiled 57 resulted in a larger object file when the 
limit was 1, while 38 resulted in a larger object file when the limit was 
2.  However, those 57 files that increased in size increased by 2008 
bytes, while those that increased when the limit was 2 increased by 2436 
bytes.  Which means that in total using a limit of 1 resulted in a net 
decrease in file size of 428 bytes (approximately 0.02%).

This is hardly significant enough to get upset about, but I think I'm 
going to revert the code to using a limit of 1 for two reasons:

1) We now have two testcases that show an increase overall, versus one 
that shows a decrease.
2) When using a limit of 2 code degradation for pathological cases seems 
to be more severe than the degradation when the limit is 1.

Reason 2 is also intuitively evident.  When the limit is set at one only 
identical constants can lead to CSE's.  So the limit on the code size 
increase is that we will always need two words per constant.  When the 
limit is higher, then the number of CSE's can increase.  This can lead to 
register starvation and spilling and the worst-case limit for this is 
clearly worse than when we handle each constant individually.

R.



More information about the Gcc-patches mailing list