RFA: Clarify requirements of process_address

Vladimir Makarov vmakarov@redhat.com
Thu Oct 25 19:52:00 GMT 2012


On 10/25/2012 05:18 AM, Richard Sandiford wrote:
> Hi Vlad,
>
> When testing other patches, I was misled by:
>
>    /* Addresses were legitimate before LRA.  So if the address has
>       two registers than it can have two of them.  We should also
>       not worry about scale for the same reason.	 */
>
> which I took to mean that process_address only handles pre-LRA addresses.
> I see now that it actually has to handle addresses created within LRA too,
> some of which might never have been valid.  That also explains why we have
> to handle invalid addresses that have no base or index, just a displacement.
>
> Here's an attempt to enumerate the cases.  Does it look OK?
> Tested on x86_64-linux-gnu.
>
It is a good start.  We definitely need to have a better understanding 
GCC addresses therefore good comments are important. It is ok for me to 
commit.  Thanks for working on this.  You make my life easier.

But  I guess it does not describe all cases, e.g. displacement was valid 
but after updating offsets for eliminated regs (because stack slots were 
allocated) it became invalid.

>
>
> gcc/
> 	* lra-constraints.c (process_address): Describe the kinds of address
> 	that we might see.
>
> Index: gcc/lra-constraints.c
> ===================================================================
> --- gcc/lra-constraints.c	2012-10-25 10:10:49.586281642 +0100
> +++ gcc/lra-constraints.c	2012-10-25 10:16:51.025280757 +0100
> @@ -2496,8 +2496,21 @@ equiv_address_substitution (struct addre
>     return change_p;
>   }
>   
> -/* Major function to make reloads for address in operand NOP.  Add to
> -   reloads to the list *BEFORE and *AFTER.  We might need to add
> +/* Major function to make reloads for an address in operand NOP.
> +   The supported cases are:
> +
> +   1) an address that existed before LRA started.  These addresses
> +      must already be valid.
I would add in non-strict sense.
>



More information about the Gcc-patches mailing list