This is the mail archive of the 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: Question about constraints and reload

On 26/09/2004, at 2:35 PM, Andrew Pinski wrote:

On Sep 26, 2004, at 5:30 PM, Geoffrey Keating wrote:

Steven Bosscher <> writes:
is there any reason to rely on reload to turn a constant into a MEM?

Yes, there is.

Consider rs6000, where there's no instruction to load a constant into
a FP register, but it's pretty easy to get a constant into a GPR.
Suppose reload is seeing a pattern like

(mov:SF (reg:SF 1234) (const_double:SF 0))

if it decides that register 1234 should be allocated to a GPR (for
instance, because it's going to be a parameter to a varargs function),
this can be coded as a 'li' instruction, an immediate load.  If it
decides to allocate it to a FPR (for instance, because it's about to
be compared with another FP value), it must be coded as a 'lfs'
instruction, a floating-point load, of a value in the constant pool.
If the zero's just being stored out to somewhere else, either choice
is acceptable and which should be picked would depend on what
registers are available.

But this breaks some testcases, see PR 17606 for an example where this causes some problems.

The fact that the chip is like this doesn't 'break' anything; it is perfectly possible to create a compiler that can generate good code for such a chip, and in fact the infrastructure in GCC is designed to be able to cope with the kinds of situation I described. The problem is that there are reload and/or backend bugs that cause this to go wrong. The solution is to find the bugs and fix them.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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