This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch 0/5] nios2 address mode improvements


On 10/19/2017 08:03 PM, Sandra Loosemore wrote:
> This is the set of nios2 optimization patches that I've previously
> mentioned in these threads:
> 
> https://gcc.gnu.org/ml/gcc/2017-10/msg00016.html
> https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00957.html
> 
> To give an overview of what this is for....
> 
> The nios2 backend currently generates quite bad code for memory
> accesses with addresses involving symbolic constants.  Like a typical
> RISC machine, nios2 requires splitting such 32-bit constants into
> HIGH/LO_SUM pairs.  Currently this happens in expand, and address
> expressions involving such constants are always converted to use a
> register indirect form.
> 
> One part of the problem is that the backend currently doesn't
> recognize that LO_SUM is a legitimate address form (it's register
> indirect with a constant offset using the %lo relocation).  That's
> fixed in these patches.
Right.  Handling this is pretty standard stuff.

> 
> A harder problem is that doing the high/lo_sum splitting in expand
> inhibits subsequent optimizations.  One such problem arises when you
> have accesses to multiple fields in a static structure object.  Expand
> sees this as many (symbol + offset) expressions involving the same
> symbol with different constant offsets.  What we should be doing in
> that case is CSE'ing the symbol address computation rather than
> splitting every such expression individually.
My memory is fuzzy, but you might want to look at the PA.

My recollection is that we had support for CSE-ing the high part of a
series of nearby accesses.  The trick was to mask the constant
displacement in the HIGH expression.  So to access x, x+1 and x+2 would
look like

high (x)
lo_sum (x)
high (x)
lo_sum (x+1)
high (x)
lo_sum (x+2)

We'd then naturally cse the HIGH expressions.

The trick here is you also need some assembler/linker support.  That's
why there's rrsel and lrsel field selectors in the PA port.

We split things as early as possible to expose the CSE opportunities for
the HIGH expressions and to encourage LICM.

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]