rl78 anddi3 improvement

Hello,

The following patch improves code size for 64 bit and for RL78:
it emits a library function call instead of emitting code for  the 64 bit
min for every single time.
The and function which was added in libgcc is hand written, so more optimal
than what GCC generates.

The change can easily be seen on the following test case:
unsigned long long my_anddi3(unsigned long long x, unsigned long long y){ 
return x & y;
}
I did not add this to the regression as it very simple and there are test
cases in the regression which test this, for example
gcc.dg/torture/stackalign/alloca-1.c  and
gcc.dg/torture/stackalign/vararg-2.c.
Regression test is OK, tested with the following command:
make -k check-gcc RUNTESTFLAGS=--target_board=rl78-sim

Please let me know if this is OK, Thank you!
Sebastian

On 12/08/2017 07:50 AM, Sebastian Perta wrote:
> Hello,
> 
> The following patch improves code size for 64 bit and for RL78:
> it emits a library function call instead of emitting code for  the 64 bit
> min for every single time.
> The and function which was added in libgcc is hand written, so more optimal
> than what GCC generates.
> 
> The change can easily be seen on the following test case:
> unsigned long long my_anddi3(unsigned long long x, unsigned long long y){ 
> return x & y;
> }
> I did not add this to the regression as it very simple and there are test
> cases in the regression which test this, for example
> gcc.dg/torture/stackalign/alloca-1.c  and
> gcc.dg/torture/stackalign/vararg-2.c.
> Regression test is OK, tested with the following command:
> make -k check-gcc RUNTESTFLAGS=--target_board=rl78-sim
> 
> Please let me know if this is OK, Thank you!
> Sebastian
> 
> Index: gcc/ChangeLog
> ===================================================================
> --- gcc/ChangeLog	(revision 255511)
> +++ gcc/ChangeLog	(working copy)
> @@ -1,3 +1,7 @@
> +2017-12-08  Sebastian Perta  <sebastian.perta@renesas.com>
> +
> +	* config/rl78/rl78.md: New define_expand "anddi3".
So I think you're ultimately far better off determining why GCC does not
generate efficient code for 64bit logicals on the rl78 target.

Once you start defining these kind of operations you'll often end up
defining more and more rather than addressing the core underlying issues.

Furthermore, defining multi-word operations will inhibit optimizations
that would have applied had the multi-word operation been broken down
into word-sized operations.  I've seen this time and time again when
32bit targets define DImode operations.  So not only will you end up
with a lot of these patterns, you then end up defining lots of special
cases for them to catch some of hte missed optimizations.

DJ has the final call here, but I think you'd be better off looking
deeper and trying to understand how to get better code for multi-word
operations without defining multi-word libcall expanders like this.

jeff

Hello Jeff,

Thank you for your comments.

>>So I think you're ultimately far better off determining why GCC does not

>>generate efficient code for 64bit logicals on the rl78 target.

I totally agree with you, this is why:
1. I have another patch: I define_expand movdi in which I instruct GCC to use 16 bit movw instead of movw, with this patch applied on the latest revision I reduce the code size of this function (my_anddi3) from 323 bytes to 245 bytes. I'm just waiting on the regression to finish I will post this patch.
2. I am working very hard for quite some time to improve/replace the "devirtualization" pass (see pass_rl78_devirt in rl78.c). I am working on a solution which will generate very similar code what I wrote in ___adddi3 and will also allow me to also change the calling convention to be efficient (similar to what the RL78 commercial compilers use) but unfortunately I still a long way from being finished (as it is quite difficult). I think DJ can explain much better why he needed to do things this way (add this pass and the *_virt and *_real variants for the instructions) in the first place.

However if you look closely at the patch you will see the that I put the following condition for the availability of the expand:
+  "optimize_size"
The idea behind this is the following:
Compared to the commercial RL78 compilers GCC is quite far behind (even 2x-3x bigger). When comparing the output code I observed the commercial compilers I saw they use quite extensively code merging techniques.
For GCC I found some work on this on a branch which didn't make to master (https://www.gnu.org/software/gcc/projects/cfo.html). I have ported this a while back to 4.9.2 but I didn't get significant code size improvement (I think I will give this another try after I finish point 2 above)
So I decided then to continue doing things this way which finally gave me some really good results (improved the code size by 30% on average, even more than 50% in some cases).
So even if/when I finish with point 2 above I think I will still like to have things done this way as they improve code size significantly.

I hope this explanation is satisfactory to you  as I have other patches (not only for 64 bit operations) which make use of the same idea.

Best Regards,
Sebastian


[https://www2.renesas.eu/media/email/unicef_2017.jpg]

This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.