Re: [PATCH] Use RTX_AUTOINC in rs6000 predicates.md

[Richard Sandiford <rdsandiford at googlemail dot com>]

David Edelsohn <dje.gcc@gmail.com> writes:
> On Thu, Jul 16, 2009 at 4:16 AM, Richard
> Sandiford<rdsandiford@googlemail.com> wrote:
>> As it turned out I needed another change. ?rs6000_mode_dependent_address_p
>> tries to check whether we can safely access subwords of a TFmode operand
>> (which I agree is the right given the current recog code, that's not the
>> problem). ?However, we treat any offset from virtual_stack_vars_rtx and
>> arg_pointer_rtx as legitimate before reload (which again seems good
>> given the way elimination works). ?But this means that any subword
>> of a TFmode access based on virtual_stack_vars_rtx or arg_pointer_rtx
>> is also legitimate, so we shouldn't treat the addresses as mode-dependent.
>>
>> Or in rtl, things like:
>>
>> ?(mem:TF (plus arg_pointer_rtx (const_int 0x20000)))
>> ?(mem:SI (plus arg_pointer_rtx (const_int 0x20000)))
>> ?(mem:QI (plus arg_pointer_rtx (const_int 0x2000F)))
>>
>> are all OK, so they should not be treated as mode-dependent.
>> At the moment, none of them satisfy offsettable_nonstrict_memref_p.
>>
>> After the change to the predicate, the split checks are redundant:
>> the operand always satisfies offsettable_nonstrict_memref_p.
>
> Why are you removing can_create_pseudo_p() from the split check?

The old code said "split this if we can create pseudos, or if the
address is (really) offsettable".  It did this because the old version
of offsettable_mem_operand allowed memories that weren't in fact
offsettable, such as reg+reg.

The splitter (via adjust_address) could fix up the unoffsettable
addresses before reload by moving the address into a new pseudo
base register.  This meant that the splitter could safely handle
things like reg+reg addresses when can_create_pseudo_p() is true,
even though the addresses aren't offsettable.

But adjust_address can't do this after reload; it just aborts.
So the old split condition required a real offsettable operand when
can_create_pseudo_p() is false.  (Splitters don't check constraints,
so we couldn't rely on the "o" constraint to do this.)  Hence the
old condition of:

  can_create_pseudo_p () || offsettable_nonstrict_memref_p (operands[4])

But now that the predicate only allows "real" offsettable operands,
"split this if we can create pseudos, or if the address is (really)
offsettable" reduces to true, because the predicates are checked
before the split condition.

Bit long-winded that, sorry ;/

Richard