GCC: Inefficient register usage?

GCC: Inefficient register usage?

[Christopher Bahns]

Hello again folks,

It seems that GCC is generating unnecessary instructions to perform
rather simple operations. A simple bitwise-or operation generates three
instructions (12 bytes), compared to one instruction (6 bytes, I assume)
generated by the Microtec Research (MRI) compiler. I suspect that this
is at least part of the reason I'm seeing a 17% increase in machine code
output size when going from MRI to GNU/GCC. I also fear that this makes
the code a bit slower. I just don't understand why GCC is doing this in
situations that appear to be obvious opportunities to save some space
(and improve performance as well?).


Here is my environment:
Windows NT 4.0 Workstation (sp6a)
Cygnus Cygwin 1.1.2
binutils-2.10
gcc-2.95.2
newlib-1.8.2
Target: m68k-coff

Here is my C-language function:
_________________________________________________
void MyFunction( void )
{
   *(volatile unsigned char*)(0xfffffffe) |= 0x40;
}
_________________________________________________

Here is the GCC assembly listing (M68000 target):
_________________________________________________
 148                .                   globl MyFunction
 149                                    MyFunction:
 154 008c 1038 FFFE        move.b -2.w,%d0
 155 0090 0000 0040         or.b #64,%d0
 156 0094 11C0 FFFE       move.b %d0,-2.w
 159 0098 4E75                  rts
_________________________________________________

Here is the MRI assembly listing:
_________________________________________________
 XDEF _MyFunction
_MyFunction:
 ori.b #64,-2
 rts
_________________________________________________


I tried various optimizations, including -O2, -Os, -fno-force-mem, and
-fno-force-addr. Mixing these four optimizations in different ways had
no effect on the output (I always used either -O2 or -Os in each case).
Other optimizations (already in use) that I assume are unrelated are
-funsigned-char, -fdefer-pop, and -fomit-frame-pointer.

However, after removing the "volatile" keyword, GCC generates the same
concise output as MRI. But, I already discovered that I *need* to use
the volatile keyword when accessing hardware registers. I really don't
see why the volatile keyword should affect this kind of optimization.

Hmm... I know that I'm using "volatile" to tell the compiler not to
optimize out certain pieces of code. But, it seems like it's avoiding
*all* possible optimizations for that line of code, not just those that
might eliminate it. I'd like to see it include the assignment in the
output (avoiding optimizations that could eliminate it), but allow other
optimizations to apply that might reduce its size or improve efficiency
without removing it entirely.

Well, I cannot just remove "volatile" from all of the places that
"appear" not to need it. I do try only to use it where it makes sense,
but that happens to be in quite a lot of places in our code. I don't
know how much overall it would save, but every little bit counts, and I
hate to see this kind of inefficiency when comparing the MRI output to
that of GNU.

Can someone advise as to why GCC is not able to (or does not want to)
optimize code that uses the "volatile" keyword without actually removing
the code? Are there any command-line options that I'm missing that may
apply to my problem? Can I rebuild the compiler in a different way to
affect its behavior?

Thanks a lot for any info.
Chris

RE: GCC: Inefficient register usage?

[Mark Powell]

I have noticed a definite worsening of gcc's optimisation for the m68k
target (and related targets such as ColdFire) since the EGCS initiative,
i.e. versions since 2.8. I guess it is due to reworkings of the gcc
internals to produce better code for the Pentiums and Sparcs. I remember one
large piece of work in the early days of EGCS was the "Haifa scheduler". I
don't know what it effect it might have had, but something like that may be
the cause of the deterioration in 68k optimisation.

I wonder if there is any switch to revert to older behaviour. Any GCC gurus
out there able to comment?

--
Mark Powell, Senior Software Engineer, Primagraphics Limited
New Cambridge House, Litlington, nr.Royston, Herts, SG8 0SS, UK
Tel. +44 1763 852222, Fax. 853324, http://www.primagraphics.co.uk



> -----Original Message-----
> From: crossgcc-owner@sources.redhat.com
> [ mailto:crossgcc-owner@sources.redhat.com]On Behalf Of Christopher Bahns
> Sent: 25 August 2000 08:48
> To: crossgcc@sourceware.cygnus.com
> Subject: GCC: Inefficient register usage?
> Importance: High
>
>
> Hello again folks,
>
> It seems that GCC is generating unnecessary instructions to perform
> rather simple operations. A simple bitwise-or operation generates three
> instructions (12 bytes), compared to one instruction (6 bytes, I assume)
> generated by the Microtec Research (MRI) compiler. I suspect that this
> is at least part of the reason I'm seeing a 17% increase in machine code
> output size when going from MRI to GNU/GCC. I also fear that this makes
> the code a bit slower. I just don't understand why GCC is doing this in
> situations that appear to be obvious opportunities to save some space
> (and improve performance as well?).
>
>
> Here is my environment:
> Windows NT 4.0 Workstation (sp6a)
> Cygnus Cygwin 1.1.2
> binutils-2.10
> gcc-2.95.2
> newlib-1.8.2
> Target: m68k-coff
[ cut ]


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: GCC: Inefficient register usage?

[Uvarov Sergey]

I'm still using gcc 2.7.2.3 and quite happy with it. But it produces the
same ugly code for the Christopher's example:

        moveb -2:w,d0
        orb #64,d0
        moveb d0,-2:w

So I think that the problem existed before the EGCS initiative. Look for
Kai Ruottu's letter "volatile again" from 27 Jan 2000 to get more
information.

	Sergey

On Fri, 25 Aug 2000, Mark Powell wrote:

> I have noticed a definite worsening of gcc's optimisation for the m68k
> target (and related targets such as ColdFire) since the EGCS initiative,
> i.e. versions since 2.8. I guess it is due to reworkings of the gcc
> internals to produce better code for the Pentiums and Sparcs. I remember one
> large piece of work in the early days of EGCS was the "Haifa scheduler". I
> don't know what it effect it might have had, but something like that may be
> the cause of the deterioration in 68k optimisation.
> 
> I wonder if there is any switch to revert to older behaviour. Any GCC gurus
> out there able to comment?
> 




------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: GCC: Inefficient register usage?

[Mark Powell]

Hm, so the volatile issue is not related to the deterioration in
optimisation.
Unfortunately, I had to upgrade to the gcc 2.95 series to get support for
ColdFire which we are now using as well as 68030.


> -----Original Message-----
> From: crossgcc-owner@sources.redhat.com
> [ mailto:crossgcc-owner@sources.redhat.com]On Behalf Of Uvarov Sergey
> Sent: 25 August 2000 11:30
> To: crossgcc@sourceware.cygnus.com
> Subject: RE: GCC: Inefficient register usage?
> Importance: High
>
>
> I'm still using gcc 2.7.2.3 and quite happy with it. But it produces the
> same ugly code for the Christopher's example:
>
>         moveb -2:w,d0
>         orb #64,d0
>         moveb d0,-2:w
>
> So I think that the problem existed before the EGCS initiative. Look for
> Kai Ruottu's letter "volatile again" from 27 Jan 2000 to get more
> information.
>
> 	Sergey
>
> On Fri, 25 Aug 2000, Mark Powell wrote:
>
> > I have noticed a definite worsening of gcc's optimisation for the m68k
> > target (and related targets such as ColdFire) since the EGCS initiative,
> > i.e. versions since 2.8. I guess it is due to reworkings of the gcc
> > internals to produce better code for the Pentiums and Sparcs. I
> remember one
> > large piece of work in the early days of EGCS was the "Haifa
> scheduler". I
> > don't know what it effect it might have had, but something like
> that may be
> > the cause of the deterioration in 68k optimisation.
> >
> > I wonder if there is any switch to revert to older behaviour.
> Any GCC gurus
> > out there able to comment?
> >
>


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: GCC: Inefficient register usage?

[Mark Powell]

Further to the volatile discussion, I saw this on the gcc-bugs list:

-----Original Message-----
From: gcc-bugs-owner@gcc.gnu.org [ mailto:gcc-bugs-owner@gcc.gnu.org]On
Behalf Of Mike Stump
Sent: 15 June 2000 23:10
To: eric@cls.usask.ca; gcc-bugs@gcc.gnu.org; joel@oarcorp.com
Subject: Re: Poor code generation for M68k volatile variables
Importance: High


> Date: Thu, 15 Jun 2000 09:32:24 -0600
> From: Eric Norum <eric@cls.usask.ca>
> To: gcc-bugs@gcc.gnu.org, Joel Sherril <joel@oarcorp.com>

> Declaring a variable `volatile' makes access to it less efficient on
> m68k targets.

Yes.  Search the mailing list archives for volatile_ok, and my name.
You will find a patch to fix the compiler, the same test case as the
test case you found, a complete discussion and so on.

The solution, if you want to push it forward, is to define a new flag

#define MD_RESPECTS_VOLATILE 1

in your port file, and go through the entire port file, and ensure
that all uses of things comply with the volatile semantics, and then
conditionalize the old patch that fixes this with the condition of
MD_RESPECTS_VOLATILE being defined and true.

Voila, there you have it.

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com