RE: new auto-inc-dec pass

[Kenneth Zadeck <Kenneth dot Zadeck at NaturalBridge dot com>]

> Hi,
> 
> I'mm currently looking at the dataflow branch for m68k mainly because of 
> the new auto-inc-dec pass, I worked a bit on the old code in flow.c, but 
> considering the new pass, I think it doesn't make much sense to continue 
> it.
> 
I agree.  With high probability the auto inc detection will be
replaced with the new auto-inc-dec.c on the dataflow branch.

I would certainly encourage you to enhance the new code in
auto-inc-dec.c where you find that it is lacking.  That code does get
all of the cases that were found by the old version of flow and does
get many things that were missed.  

But there is no expectation that this is the last word in auto-inc-dec
detection.  My main concern was to cleanly separate this function from
flow without any regressions.


> 
> 
> I'm attaching my current patch and some test cases, but before delving 
> deeper into the code, I have a few questions and I'd like to hear some 
> opinions. Currently I only looked at the output and it misses some 
> opportunities (not that my patch can do everything either :) ).

I agree that the auto-inc-dec code will already get much of this.  In
particular there is no longer (unless the machine requirres it) a
reliance that the increment match the size of the load or store. 
> 
> One case is about multiple increments, the tree optimizer merges them and 
> increments the register only once, so if one only looks at the size of the
> pointer value one misses them, e.g. something like this:
> 
> 	(set (mem (reg)) (x))
> 	(set (mem (plus (reg) (const_int 4))) (x))
> 	(set (reg) (plus (reg) (const_int 8))
> 
> Another case are multiple uses of the register within an instruction, the 
> old code didn't do this at all, the new code seems to do a bit better, but 
> there as a rather tricky case I looked into, e.g.
> 
> 	(set (mem) (plus (mem) (reg)))
> 
> could be turned into:
> 
> 	(set (post_inc (mem)) (plus (mem) (reg)))
> 
I do find this a little wierd but if it makes a difference go for it.


> or
> 
> 	(set (mem) (plus (pre_dec (mem)) (reg)))
> 
> This is at least what operands_match_p() accepts, but hasn't been 
> generated in a long time and has the potential to trigger bugs in the 
> back end (e.g. m68k only looks only at one of the operands).
> A question would be now if there is a general interest in reactivating 
> this, so gcc could generate a instruction like "add.l %d0,(%a0)+" for 
> m68k.
> 
> The more general question is whether someone is already working on further 
> improvements, so I won't duplicate anything (which wouldn't be before I 
> looked into the remaining m68k dataflow problems anyway. :) ).
> 
We have stopped development on this piece of code.  It is efficient
and works with no regressions on arm, ppc and ia-64.  So it meets the
minimun criteria for inclusion onto mainline with the upcoming merge.

However, that should in no way stop anyone else from enhancing it further.

> The dataflow porting document mentions other possible, but doesn't mention 
> any examples. Anything I might have to look out for regardings the m68k 
> post_inc/pre_dec addressing modes?
> 
> bye, Roman

Kenny