On Wed, 2011-01-26 at 14:55 +0000, James Murray wrote:
> On Wed, 2011-01-26 at 15:40 +0100, Richard Guenther wrote:
>
> > Stephane Carrez is listed as maintainer of the port, so he should
> > know how to contribute fixes to the port upstream.
> >
> Yes, but as I said... he is no longer active on this port. His last
> published contributions are 4+ years ago.
I've spent a some time looking at this and can honestly say I'm very
likely out of my depth.
As a first step in bringing the port forwards, I worked on 3.4.4 as that
was fairly contemporary with 3.3.6. I manually applied the changes that
Stephane Carrez had made. The compiler builds and can generate code.
However, the generated code isn't as good as the output from 3.3.6. I
swapped back to unpatched 3.4.4 and compared with unpatched 3.3.6.
Take the following example:
------------
#define PORTA (*((volatile unsigned char*)(0x0000)))
#define PORTB (*((volatile unsigned char*)(0x0001)))
#define PORTT (*((volatile unsigned char*)(0x0240)))
#define SYNC_SYNCED 0x1
#define SYNC_SEMI 0x8
#define SYNC_SEMI2 0x10
extern unsigned char synch;
int main()
{
if ((PORTT & 0x01) == 0) {
PORTA |= 0x80;
}
if (PORTT & 0x02) {
PORTA |= 0x40;
}
if ( (!(synch & SYNC_SYNCED)) && (!(synch & SYNC_SEMI)) && (!(synch
& SYNC_SEMI2))) {
PORTB = 0x23;
}
return (0);
}
------------
m68hc11-elf-gcc -g -Wall -Werror -O -fomit-frame-pointer -m68hcs12
-mshort -msoft-reg-count=5 -mauto-incdec -fsigned-char -S test4.c
With 3.3.6 (unpatched), the resultant code (trimmed) is:
------------
main:
ldab 576
clra
andb #1
bne .L2
tfr d,x
bset 0,x, #-128
.L2:
ldab 576
clra
andb #2
beq .L3
bset 0, #64
.L3:
ldab synch
clra
andb #25
bne .L4
movb #35,1
.L4:
clra
clrb
rts
------------
The 8bit bit tests are a little sub-optimal, but workable.
Now, with 3.4.4
------------
main:
movw _.d1,2,-sp
ldab 576
clra
eorb #1
anda #0
andb #1
tbeq d,.L2
.LM3:
bset 0, #-128
.L2:
ldab 576
anda #0
andb #2
tbeq d,.L3
bset 0, #64
.L3:
xgdx
clra
ldab synch
tfr d,x
anda #0
andb #1
tbne d,.L4
tfr x,d
anda #0
andb #8
tbne d,.L4
tfr x,d
anda #0
andb #16
tbne d,.L4
movb #35,1
.L4:
ldd #0
movw 2,sp+,_.d1
rts
------------
This resultant code is significantly larger and slower. I was able to
backtrack through SVN to the majority of this change:
------------
2003-07-02 Jeff Law <l...@redhat.com>
* expr.c (do_store_flag): Remove special case folding for
single bit tests. Instead call back into the commonized folder
routine.
* fold-const.c (fold_single_bit_test): New function, mostly
extracted from do_store_flag, with an additional case extracted
from fold.
(fold): Call fold_single_bit_test appropriately.
* tree.h (fold_single_bit_test): Prototype.
------------
The changes there adversely impacted the hc11 output. The code generated
immediately after this change is even worse than the 3.4.4 output above
- instead of "andb #8" the code does three right-shifts before "andb #1"
i.e.
-----------
.L2:
ldab 576
lsrd
clra
andb #1
beq .L3
.loc 1 17 0
bset 0, #64
.L3:
xgdx
clra
ldab synch
xgdx
stx _.d1
tfr x,d
clra
andb #1
bne .L4
ldd _.d1
lsrd
lsrd
lsrd
clra
andb #1
bne .L4
ldd _.d1
lsrd
lsrd
lsrd
lsrd
clra
andb #1
bne .L4
movb #35,1
.L4:
-----------
I'm sure that the changes must have had a positive effect on other
targets, but the core of that code (.L3-.L4) is five times larger than
the 3.3.6 output.
What would be the best approach to address issues like this?
Create new m68hc11.md rules to pick up the newly generated RTL and turn
it back into optimal code or???
i.e. if Stephane Carrez had continued maintaining the m68hc11 target,
how would he have been keeping up with core changes that had a negative
impact on m68hc11 ?
My rationale here is that if I'm unable to make changes to preserve
output code quality for a small change like this, then there is no
chance of me working through the other eight years of changes...(!)
The alternative is that I work on adding a few enhancements to 3.3.6 as
that's what is being used in production by a number of different project
teams.
regards
James Murray
PS. Yes I know I'm quoting a ChangeLog entry from 2003 and also that
m68hc11 has been removed from gcc now. But please humour me..
