Re: Subreg splitting and floating point

[Jeff Law <law at redhat dot com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/06/11 07:58, Frederic Riss wrote:
> On 6 January 2011 15:27, Ian Lance Taylor <iant@google.com> wrote:
>> Frederic Riss <frederic.riss@gmail.com> writes:
>>> ../gcc/testsuite/gcc.c-torture/execute/ieee/930529-1.c:27:1: error:
>>> unrecognizable insn:
>>> (insn 45 2 46 2
>>> ../gcc/testsuite/gcc.c-torture/execute/ieee/930529-1.c:2 (set
>>> (subreg:SI (subreg:DF (reg/v:DI 136 [ d ]) 0) 0)
>>>         (const_int 2454267026 [0x92492492])) -1 (nil))
>>>
>>> My other option is to disable subreg-splitting on my port, but I
>>> wonder what adverse effects it could have on 64bits integral code.
>>>
>>> What is the correct way to deal with this?
>>
>> Setting MODES_TIEABLE_P is the right way to control lower-subreg.  Your
>> problem lies elsewhere.  gcc requires that all simple moves be handled
>> by the backend one way or another, and the above insn is a simple move.
>> Why is it not recognized?  Is register 136 a pseudo or a hard register?
>> If a hard floating point register, how do you load a constant into a
>> floating point register?
> 
> 136 is a pseudo. I have movdf and movsf patterns that accepts
> constants. I'm not sure what happens. Also, strictly speaking, the
> unrecognized pattern above is a SI move and not a floating point move,
> isn't it?
> 
> I managed to get thinks going by constraining MODES_TIEABLE_P and
> adding 2 patterns of the form:
> 
>  [(set (subreg:SI (match_operand:DF 0 "register_operand" "=r") 0)
>        (match_operand 1 "immediate_operand" "i"))]
> and
>  [(set (subreg:SI (match_operand:DF 0 "register_operand" "=r") 4)
>        (match_operand 1 "immediate_operand" "i"))]
> 
> This result lead me to think that MODES_TIEABLE_P also controls what
> kind of subreg expressions are allowed and thus prevented the initial
> pattern from being matched, is that true? Note that splitting DF
> values in SI subparts is exactly what I prevented by my
> MODES_TIEABLE_P modification.
> 
> In the current form, all the testsuite passes, and I get the code
> generation I want, but I'm not really fond of the (set (subreg:SI
> (reg:DF) ...) rules that I added.
You're definitely papering over a problem elsewhere in your port.

Jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNJeB0AAoJEBRtltQi2kC7tHgH/REcO4zkU+cbemn3vPSYLYXs
nLxyt2Hya/B4HGzVS2gvrIivnZDJxViVYPLL5wnJQb8co4yK870cWzkAEW936OVb
n0gaYCGrR3jr38GtskROwy7JyHNvRfWXI7QWxb8NTuFKj2O+AruP2zLpCDMbSR5b
3gkMBwQauzKd0qSBdcQYUT7wWW5MkJhovCBMyVVdJ1Yde/M8rYIbE687KemFMYFT
fNYkx6GeRwtoFIudYNvVtnngfpPTb313KpDKGG9lcQlxkfuBFFsCR2olPrMboPhs
PH2SrifOoG0ykKW0K4Eaiy/ks/Z/Mg6DiaYYISsvszjx618UG3AE7RUw4cAgZRg=
=NUA9
-----END PGP SIGNATURE-----