Re: Autoincrement patches

Re: Autoincrement patches

[Joern Rennecke]

Hmmm, I just recognize that PRE_MODIFY / POST_MODIFY is more complicated
than I thought - you have to pass it a complete SET_SRC.
Is there any indication that we'll really need that much flexibility?
Or could we just include the offset by which the register is incremented?

Re: Autoincrement patches

[Michael Hayes]

Joern Rennecke writes:
 > Hmmm, I just recognize that PRE_MODIFY / POST_MODIFY is more complicated
 > than I thought - you have to pass it a complete SET_SRC.
 > Is there any indication that we'll really need that much flexibility?
 > Or could we just include the offset by which the register is incremented?

Ideally yes.  When I designed the functionality for
PRE_MODIFY/POST_MODIFY I wanted to be able to handle other esoteric
addressing modes used by DSPs, such as for creating circular buffers
and bit-reversed addressing.  

Michael.

Re: Autoincrement patches

[Michael Hayes]

Joern Rennecke writes:
 > Hmmm, I just recognize that PRE_MODIFY / POST_MODIFY is more complicated
 > than I thought - you have to pass it a complete SET_SRC.
 > Is there any indication that we'll really need that much flexibility?
 > Or could we just include the offset by which the register is incremented?

Ideally yes.  When I designed the functionality for
PRE_MODIFY/POST_MODIFY I wanted to be able to handle other esoteric
addressing modes used by DSPs, such as for creating circular buffers
and bit-reversed addressing.  

Michael.

Re: Autoincrement patches

[Joern Rennecke]

Hmmm, I just recognize that PRE_MODIFY / POST_MODIFY is more complicated
than I thought - you have to pass it a complete SET_SRC.
Is there any indication that we'll really need that much flexibility?
Or could we just include the offset by which the register is incremented?

Re: Autoincrement patches

[Michael Hayes]

Joern Rennecke writes:
 > 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.


Michael.

Re: Autoincrement patches

[Joern Rennecke]

>  > 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;

Re: Autoincrement patches

[Joern Rennecke]

>  > 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;

Re: Autoincrement patches

[Michael Hayes]

Joern Rennecke writes:
 > 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.


Michael.