Autoincrement patches
Joern Rennecke
amylaar@cygnus.co.uk
Fri Dec 31 23:54:00 GMT 1999
> > I think I can integrate the generation of PRE_MODIFY / POST_MODIFY for
> > constant displacements into my patch, but incrementing by a register
> > won't quite fit.
>
> Pity, since this optimisation is very important for things like matrix
> multiplication.
>
> > Do you think this functionality of your patch can be reasonably separated
> > from the rest?
>
> I don't think so since it uses the same infrastructure. Maybe using
> SSA it could be simplified a little.
I'm currently trying to figure out if this optimization could share
infrastructure with my patch. I suppose I already have most of the
required information (i.e. where are adds, and where are MEMs), and
the rest shouldn't that hard to come by.
My main concern is destructive interaction of the different optimizations -
i.e. one relies on some information gathered beforethe other changed
the RTL, and the end result is incorrect code.
So in order to assess the actual problem better, I need to understand what
the preconditions for the register PRE/POST_MODIFY optimization are.
I.e. if the add is before the memref, can the sum be used anywhere
before the memref to be turned into PRE_MODIFY?
I would guess not; and if it can't, it won't be a member of a set of
related values, i.e. no problem there.
The increment is also in a register, which could well be in a set of
related values. The issue here is that the lifetime of the increment
register is possibly extended. So the death information would have to be
updated, a mere bookkeeping operation at this stage, but it must not
be omitted.
Things seem more tricky for POST_MODIFY. In my current scheme, when a
(mem (plus (reg 1) (reg 2))) is seen, the code just sees two registers
that are referenced in a way that can't be optimized further at this point.
but they are both expected to retain their value.
And the memory location of their reference.
So if the POST_MODIFY optimization is applied, the incremented register
would have to get an invalidate_luid if it is in a set of related values,
and the location of both the incremented register and the increment would
have to be updated.
Do you make any attempts to squeeze out further references to the incremented
register between the memref and the increment?
That would pose further porblems.
The comments in some of your code seem to be out of sync with the code.
+ /* Scan the list of NUM memrefs in PLIST for REGNO to see which
+ ones can be converted to autoincrements. X is the rtx within the insn
+ INCR that increments REGNO and PRE is 1 if INCR precedes the memrefs
+ of REGNO. Return the number of memrefs converted to autoincrements. */
+ static int
+ autoinc_search (ref_info, regno, incr_ref, ref2, pre, ret)
+ struct ref_info *ref_info;
+ int regno;
+ struct ref *incr_ref;
+ struct ref *ref2;
+ int pre;
+ struct ref **ret;
More information about the Gcc
mailing list