[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
Wed Dec 1 22:08:00 GMT 2004
------- 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
More information about the Gcc-bugs
mailing list