Question about constraints and reload

[Geoff Keating]

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

>
> On Sep 26, 2004, at 5:30 PM, Geoffrey Keating wrote:
>
>> Steven Bosscher <stevenb@suse.de> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2410 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20040927/36a951ec/attachment.p7s>