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]

Fw: [Bug middle-end/18641] [4.0 Regression] Another ICE caused by reload ofa psuedo reg into f0 for a DImode expr





Hello Richard,

related to PR 18641, the question came up how to allow the middle-end to
deduce whether or not the result of LEGITIMIZE_RELOAD_ADDRESS is an
offsettable address or not.  You may look at the PR log for more info.

Do you have some suggestions how (or whether) to implement such an
interface?

Possibilities would appear to include:
- L_R_A must always return offsettable addresses
- A global target macro (as suggested by David below)
- A fine-grained flag set by L_R_A for each case

Thanks,
Ulrich


"dje at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> wrote on 11/24/2004
07:19:03 PM:
> ------- Additional Comments From dje at gcc dot gnu dot org
> 2004-11-24 18:18 -------
> Allowing the middle-end to know that the L_R_A address is offsettable
looks
> like a better solution to me.  The design is an issue for RTH.  One
> possibility is a target macro to decide if L_R_A addresses should be
assumed
> offsettable:
>
> #if LRA_OFFSETTABLE
>       || address_reloaded[i] > 0
> #else
>       || address_reloaded[i] == 1
> #endif
>       )
>
> Finer granlarity information from LRA is more complicated.
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18641
>
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.


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