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

["fjahanian at apple dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Additional Comments From fjahanian at apple dot com  2004-12-01 22:07 -------
Regardless of how we fix this specific problem; by reverting Ulrich's patch to find_reloads_address, 
making the small change he proposed in find_reloads, or something else, there remains the
problem each time a 64-bit integer constant is loaded into an FPR. This is a cronic problem which
we need to address. Now is as good as ever. Being a newby in this area please bear with me.

I see a couple of solutions:

1) Do not use FPR for a 64-bit constant integers. This is indeed what happens when reverting Ulrich's
    patch. What benefit do we gain by allowing use of FPR for these cases? Don't we always need to
    eventually load the constant into a pair of GPRs, via going to memory first. What are the cases where
    using FPR is beneficial (to reduce register pressure is one answer, but then we still need to go
    to memory and back to GPRs for any useful operation).

2) Handle this special case in the splitter which is used. But this requires going to memory. Can this
    be done in the splitter? This seems to be a better solution if 1) cannot be disallowed. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18641