This is the mail archive of the
mailing list for the GCC project.
Re: Autoincrement examples
- To: m dot hayes at elec dot canterbury dot ac dot nz (Michael Hayes)
- Subject: Re: Autoincrement examples
- From: Joern Rennecke <amylaar at cygnus dot co dot uk>
- Date: Fri, 19 Nov 1999 16:48:46 +0000 (GMT)
- Cc: amylaar at cygnus dot co dot uk, m dot hayes at elec dot canterbury dot ac dot nz, law at cygnus dot com, gcc at gcc dot gnu dot org, amylaar at cygnus dot com
> > - By processing each register separately, you miss register-register
> > copies and three-address adds. Optimizing code with such constructs
> > was actually the main objective of my patch. It actually reduces
> > register pressure.
> I have rarely found these cases to be important for autoinc address
> generation. However, reduction of register pressure is a good thing.
It gets pretty important with my loop patches applied.
> > - Your code can generate PRE_MODIFY / POST_MODIFY, something which mine
> > can't.
> Yes, this is important for DSP architectures; especially things like
> matrix multiplication where you want a large stride.
My patch can also modified to accomodate this, but for an efficient
implementation, this wants a balanced tree instead of a hash table.
Just like rewriting (mem (plus (reg ..) (const_int ..))) .
I have some AVL code, but I haven't assigned the deletion to the FSF and
I really need the code somewhere else, too. So maybe it'll be best to go
with splay trees. I understand we already have code for that in the source
> With the information that I collect, these transformations would be
> straightforward. More importantly, I would like to reorder some of
> the memory references to improve autoinc generation.
Which gets us into aliasing problems... well, I suppose it's easier these
days, now that the alias code is centralized.
> Does your code maintain the LOG_LINKS? If so I would like to try
No, it doesn't.
> running the instruction combiner after the regmove pass.
> Alternatively, could your code be easily modified to remove redundant
> load instructions once an autoinc address was generated?
Could you sketch an rtl example of the transformation you have in mind?