Re: Register allocation (sumesh)
21 Jul 2003 21:33:10 -0400

          From comp.compilers

Related articles
Register allocation (2003-07-04)
Re: Register allocation (TOUATI Sid) (2003-07-15)
Register allocation (Rob Thorpe) (2003-07-21)
Re: Register allocation (2003-07-21)
Re: Register allocation (2003-07-21)
Re: Register allocation (Dan) (2003-07-21)
Re: Register allocation (2003-07-31)
Register allocation (2004-07-15)
Re: Register allocation (2004-07-28)
Re: Register allocation (Rajaram) (2004-08-04)
[25 later articles]
| List of all articles for this month |

From: (sumesh)
Newsgroups: comp.compilers
Date: 21 Jul 2003 21:33:10 -0400
References: 03-07-058 03-07-097
Keywords: registers, optimize
Posted-Date: 21 Jul 2003 21:33:10 EDT

      My question was more about knowing if any register promotion pass
is needed to remove such redundant load/stores of induction variables.
  Or would standard optimizations like strength reduction/ code motion
be good enough.

                When comparing between gcc for sparc and the code produced by
gcc cross compiler for MCORE, I found the former doing a better job.
The example was a simple loop with an assignment A[i] = i, 'A' being
an array and i being the induction vsriable. ideally it should be
possible to do this using just one store inside the loop but that
doesnt happen. gcc-sparc uses 2 loads/stores, gcc-MCORE uses 3. Is
there any exisiting technique which can be used to eliminate the
redundant store of the induction variable in the loop.


TOUATI Sid <> wrote
> It is hard to say why a compiler didn't make this or that optimization.
> Maybe the number of free registers isn't sufficient (I am not familiar
> with the MCORE platform).
> However, be sure that gcc isn't the most efficient compiler in terms of
> code optimization, especially with backend opptimization. Maybe by using
> the keywork "register" for your global variables, you can help gcc to
> decide.

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.