gcc-3.3 with -fomit-frame-pointer finally works on ColdFire

[Bernardo Innocenti]

On Monday 28 July 2003 17:28, Peter Barada wrote:

> >It would be nice to port some of these changes to HEAD. Peter, are
> >you planning to do this? I'm still waiting to receive my copyright
> >assignment from the FSF via snail mail.
>
> Its great to hear that you have it working!

Yeah, I was almost loosing hope, but now I'm very satisfied! :)


> I've been so buried under work trying to get away for a week's
> vacation that I haven't had a chance to look at *any* of the ColdFire
> stuff for the month of July.  When you get a complete patch together
> against my tree(@baradas.org), send me a mail, I'll integrate it, and
> then start adding my v4 changes to it...

I'm afraid splitting everything up would be a bit difficult. My patches
are all layered one on top of the other and have lost most of their
original identity.

These came from your CVS tree (both 3.2.3 and 3.3, with some small
fixes and changes for 3.3.1):

 gcc-3.3.1-coldfire-targets.patch
     rename TARGET_M5200 to TARGET_COLDFIRE and add new Coldfire targets

 gcc-3.3.1-coldfire-frame.patch
     ColdFire optimized frame layout + attribute((interrupt))
     I removed m68k_initial_elimination_offset() since it is unused.

These patches come from Paul Dale's 2.95.3 work on the uClinux toolchain:

 gcc-3.3.1-uclinux-idshlib.patch
     Add -mid-shared-library and -msep-data

These are my additional patches:

 gcc-3.3.1-coldfire-omitfrmptr.patch
     Fix -fomit-frame-pointer by moving ARGPTR to a distinct
     regno. Simplify and optimize ColdFire prolog and epilog
     generation.

 gcc-3.3.1-uclinux-thunk.patch
     Add -mid-shared-library support for thunks

 gcc-3.3.1-uclinux-specs.patch
     Tweak the specs for building uClinux apps (this one
     really needs to be rewritten from scratch)

 gcc-3.3.1-libstdc++-atomicity.patch
     Fix atomic stuff for ColdFire ISA_A cores

 gcc-3.3.1-libstdc++-nowchar.patch
     Fix build with uClibc with disabled wchar_t support


The problem is that some of these patches overlap each other
and are quite invasive. I've done by best to keep them
separate and I've even splitted them in smaller pieces when
it made sense and it was easy enough.

I'll have to split the patches even more if I want them to be
acceptable. Besides, the recent cleanups in the m68k backend
- which are a GoodThing(tm) - will make my patches difficult
to merge on HEAD.

It's too bad we've lost the GCC 3.4 train. The branch is already
in stage 2, and GCC 3.5 is very far away :-(


> I'm still looking into the ColdFire reload problem(attempt to load a
> QImode value from memory into an address register), but without much
> success.  I think I have to learn a *lot* more about reload before I
> can understand where its going wrong.

So I still need to keep that fix in reload you suggested some weeks
ago, right?

I've not yet grasped any of the RTL complexity so far, let alone the
optimizers :-)

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html