Denis Chertykov schrieb:
2011/6/14 Georg-Johann Lay <a...@gjlay.de>:
Denis Chertykov schrieb:
2011/6/13 Georg-Johann Lay <a...@gjlay.de>:
So you think is is pointless/discouraged to give a more realistic
description of AVR addressing be means of MODE_CODE_BASE_REG_CLASS (instead
of BASE_REG_CLASS) resp. REGNO_MODE_CODE_OK_FOR_BASE_P?
Look carefully at `out_movqi_r_mr'.
There are even two fake addressing modes:
1. [Y + infinite-dslacement];
2. [X + (0...63)].
Yes, I know. The first is introduced by avr_legitimate_address_p and the
second appears to be artifact of LEGITIMIZE_RELOAD_ADDRESS.
The changes are basically MODE_CODE_BASE_REG_CLASS (introduced in 4.2) and a
rewrite of avr_legitimate_address_p. The changes aim at a better addressing
for X and to minimize fake addresses.
I have spent a many hours (days, months) to debug GCC (especially avr port
and reload) for right addressing modes.
I have stopped on this code.
AVR have a limited memory addressing and GCC can't handle it in native
form.
Because of that I have supported a fake adddressing modes.
I assume the code is from prior to 4.2 when REGNO_MODE_CODE_OK_FOR_BASE_P
and MODE_CODE_BASE_REG_CLASS had not been available so that supporting X
required some hacking.
All that would still be fine; however the new register allocator leads to
code that noone would accept. Accessing a structure through a pointer is not
uncommon, not even on AVR. So if Z is used for, say accessing flash, X
appears to be the best register.
The shortcoming in GCC is that there is no way to give costs of addressing
(TARGET_ADDRESS_COST does different things).
So take a look what avr-gcc compiles here:
http://gcc.gnu.org/bugzilla/attachment.cgi?id=22242
I saw similar complains in forums on the web.
(Richard Henderson have a different opinion: GCC can, AVR port can't)
What does he mean with that?
IMHO that three limited pointer registers is not enough for C compiler.
Even more with frame pointer it's only two and X is a very limited.
The current implementation has several oddities like
* allowing SUBREGs in avr-legitimate_address_p
* changing BASE_REG_CLASS on the fly (by means of reload_completed)
isn't that supposed to cause trouble?
You can try to remove all oddities and check results.
Definitely something changed in GCC core since I wrote addressing code.
Denis.
For your interest, here is a patch that shows the changes in
addressing mode.
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01029.html
Generally, the patch seems as a "right thing". I like it.
How about a regression testing and code quality.
Denis.
I tested on some handcrafted examples and on the code attached to
PR46278. The generated code looked very good and so I started regression
testing but found at spill fail in
gcc.c-torture/compile/950612-1.c
As I don't know how to fix a spill failure I stopped working on the
patch. Perhaps it would help to have fake y+const addresses; I didn't try.
As far as I remember, reload emits inefficient code in some situations
when it tries to fit address into available addressing mode by adding
constant. I could fix that by new constraint alternative in addhi3 insn,
something like "=*!r,r,n". But that are just details.
The major work left to be done are fixing spill fails and implementing
appropriate LEGITIMIZE_RELOAD_ADDRESS which are beyond my skills.
BTW, fixing PR48459, Richard ran immediately into a spill failure during
newlib build:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459#c20
Johann
