-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/06/11 07:58, Frederic Riss wrote: > On 6 January 2011 15:27, Ian Lance Taylor <i...@google.com> wrote: >> Frederic Riss <frederic.r...@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-----
