This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Illegitimate address in REG_EQUAL note: legal?


> Index: local-alloc.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/local-alloc.c,v
> retrieving revision 1.102
> diff -c -p -r1.102 local-alloc.c
> *** local-alloc.c   2002/02/19 02:53:13  1.102
> --- local-alloc.c   2002/03/05 17:37:49
> *************** update_equiv_regs ()
> *** 946,951 ****
> --- 946,959 ----
>        if (note && GET_CODE (XEXP (note, 0)) == EXPR_LIST)
>          note = NULL_RTX;
> 
> +      /* Reload assumes that REG_EQUIV notes contain either a
> +         legitimate memory operand, or else a constant rtx as
> +         accepted by function_invariant_p.  Take care to not
> +         generate anything else.  */
> +      if (note && !memory_operand (XEXP (note, 0), VOIDmode)
> +          && !function_invariant_p (XEXP (note, 0)))
> +        note = NULL_RTX;
> +
>        if (REG_N_SETS (regno) != 1
>            && (! note
>             || rtx_varies_p (XEXP (note, 0), 0)
> 
> Do you think this could be a step in the right direction?  I don't
> completely understand all the implicit assumptions made by reload
> and others, so I'm somewhat hesitant here ...

Neighter I do, but I would guess this is fine.
We also create REG_EQUIV notes pre-reload for stack slots. There
is some risc that we will manage gcse to mangle these REG_EQUIVs
to not match reload's point of view, but I can't come with any sane
testcase so I guess it won't happen.

Honza
> 
> 
> Mit freundlichen Gruessen / Best Regards
> 
> Ulrich Weigand
> 
> --
>   Dr. Ulrich Weigand
>   Linux for S/390 Design & Development
>   IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
>   Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]