[RFC PATCH, i386]: Rewrite pop patterns to use POST_INC memory operands

[Uros Bizjak]

On Mon, Aug 30, 2010 at 7:47 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, Aug 30, 2010 at 10:40:30AM -0700, Richard Henderson wrote:
>> On 08/30/2010 10:15 AM, Uros Bizjak wrote:
>> > I will wait for eventual comments due to scary %%% comment (this is
>> > also why the patch is in the RFC state ATM).
>>
>> I'm sure I'm not aware of all the dataflow changes in the past years,
>> so I have no real constructive feedback as to whether it should be
>> expected to work now.
>
> I must say I'm very surprised if the patch works reliably, there are many
> #ifdef AUTO_INC_DEC guarded hunks and not all of them are related only
> to automatic inc/dec additions, but just whether the code should look for
> PRE/POST_INC/DEC/MODIFY in the IL.  E.g. cleanup_auto_inc_dec
> in the combiner.c to give some example.
> And, cselib does very poor job with inc/dec addressing currently (except for
> var-tracking which removes inc/dec addressing from the IL before feeding it
> into cselib).

I have investigated this a bit. As you noted, i386 is NOT AUTO_INC_DEC
target, so transformations that you refer to are simply disabled. More
important, generic code does not care about "pop" pattern at all.
These patterns are called from i386.c exclusively when constructing
prologue/epilogue - this already adds correct CFA notes to the pattern
(I wonder if they are needed at all). The only processing of these
patterns happens in peephole2s that are updated for changed
description.

I think that my patch better describes the "pop" instruction, so I
propose that we proceed with (now requalified as a cleanup) patch.

Uros.