This is the mail archive of the gcc@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: [RFC] Addressing Mode Selection Issues.


Jim Wilson Wrote:
> > No responses on this yet. So I request again. 
> > I am cc-ing SH and IA-64 maintainers this time.
> > base+large_offset abstraction might benefit IA64.
> 
> My time is consumed fixing IA-64 gcc bugs, answering questions, and
> trying to help review patches for bug fixes.  I am not doing any
> optimization related work at this time.  I don't have time 
> for it.  I'm leaving it for others.

Thanks for thinking about this. I understand the time constraints.
 
> There is only so much that is reasonable for gcc to do to try to work
around
> deficiencies of the SH architecture. I consider a 4-bit displacement to be
a 
> deficiency.

Yes. Some other architectures have displacement limits (PA, V850)
but SH is an extreme case. If the proposed implementation is useful for 
other ports, it would be good.
 
> For IA-64, yes, the lack of reg+offset addressing is a major 
> bummer.  We
> will have to do something about it eventually.  Offhand, I don't know
> what we should do to solve it.
> 
> > > One solution could be to fake the standard addressing 
> modes, the rtl
> > > optimizers are comfortable with. And change to target's 
> > > addressing mode
> > > in a separate pass after sched1.
> 
> It is impossible to say whether this is a good idea without 
> implementing it first to see.  

It would be useful till sched1. I hope better alias capability
will do the trick. But, yes, generating good code will require 
experimentation.

> This would be a significant change, so you need good
> justification for it, such as test results for several targets.

I will keep that in mind.

> I doubt this would work well for CISC targets.  It is asking too much
> for the new optimization pass to create the complicated addresses that
> exist on CISC.  Even for RISCs, it may be asking a lot.  You 
> would need a bunch of optimizations like cse/combine/splitting/etc to
avoid

It needs to deal with control flow too. That adds to the complexity.
If it turns out to be too complicated for CISCS then this can be flag
enabled 
option. I will try that it works atleast for RISCs.
 
> You have said nothing about auto-inc addresses.  These can be a curse,
> restricting scheduler freedom, but they can also be a blessing in some
> cases such as inner loops.  This is another thing you new optimization
> pass would have to create.

Missed to state it explicitly. I have auto inc-dec modes in mind. 

Thanks for ideas and the analysis. 

Regards,
Naveen Sharma.


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