RE: [PATCH] rl78 anddi3 improvement

[Sebastian Perta <Sebastian dot Perta at renesas dot com>]

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.