From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5516 invoked by alias); 17 Oct 2004 02:41:27 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 5509 invoked from network); 17 Oct 2004 02:41:26 -0000 Received: from unknown (HELO sccrmhc12.comcast.net) (204.127.202.56) by sourceware.org with SMTP; 17 Oct 2004 02:41:26 -0000 Received: from [10.69.69.128] (c-67-169-96-182.client.comcast.net[67.169.96.182]) by comcast.net (sccrmhc12) with SMTP id <2004101702412501200fqstme>; Sun, 17 Oct 2004 02:41:25 +0000 In-Reply-To: <20041017013020.GA6270@redhat.com> References: <20041015213039.GA7011@redhat.com> <20041016023058.GA9787@redhat.com> <20B4F160-1FB9-11D9-A03C-000A95B1F520@geoffk.org> <20041017013020.GA6270@redhat.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--585398830; protocol="application/pkcs7-signature" Message-Id: <09F32B26-1FE6-11D9-8BC7-000A95B1F520@geoffk.org> Cc: gcc@gcc.gnu.org From: Geoff Keating Subject: Re: rfc: constant pool and floats Date: Sun, 17 Oct 2004 16:58:00 -0000 To: Aldy Hernandez X-SW-Source: 2004-10/txt/msg00669.txt.bz2 --Apple-Mail-2--585398830 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Content-length: 3410 On 16/10/2004, at 6:30 PM, Aldy Hernandez wrote: > Thanks for taking the time on this. > >>>> That's the problem. Clearly, (reg:SF 120) is not equal to the >>>> CONST_INT; it's equal to a SFmode CONST_DOUBLE. >>> >>> I played around kludging the REG_EQUAL to be equal to a CONST_DOUBLE. >>> That didn't fix the problem because when we fill in the constant pool >>> (force_const_mem) with the value, we fill it in with a >>> const_int/SFmode >>> pair, which still causes the abort while dumping the constant pool. >> >> Where did the CONST_INT come from, if not the REG_EQUAL note? > > Ah, see below. > >>> /* If VALUE is a floating-point mode, access it as an integer of the >>> corresponding size. This can occur on a machine with 64 bit >>> registers >>> that uses SFmode for float. This can also occur for unaligned >>> float >>> structure fields. */ >>> if (GET_MODE_CLASS (GET_MODE (value)) != MODE_INT >>> && GET_MODE_CLASS (GET_MODE (value)) != MODE_PARTIAL_INT) >>> value = gen_lowpart ((GET_MODE (value) == VOIDmode >>> ? word_mode : int_mode_for_mode (GET_MODE >>> (value))), >>> value); >> >> This code is not wrong, as such, but I'm a bit confused about what >> then >> happens to 'value'. The routine appears to return it, but there's no >> documentation about what the routine is *supposed* to return, and >> every >> use of it in the compiler appears to ignore the return value. >> >> Anyway, what you want to look for is the first point where SFmode and >> CONST_INT get associated with each other. > > The code above sets 'value' to the const_int. Further down we recurse > into > store_bit_field: > > /* Fetch that unit, store the bitfield in it, then store > the unit. */ > tempreg = copy_to_reg (op0); > => store_bit_field (tempreg, bitsize, bitpos, fieldmode, value); > > Where: > tempreg = (reg:SI 119) > fieldmode = SFmode > value = (const_int 1202908642) > > Store_bit_field eventually calls emit_move_insn with: > dst = (subreg:SF (reg:SI 119) 0) > src = (const_int xx) > > *This* is the first time we associate an SF with a const_int. Aha! So it should not do that. I think the right thing to do is to pass the original VALUE here, but if that doesn't work, try passing the mode of VALUE instead of FIELDMODE (the mode of VALUE is the mode that got passed to gen_lowpart). > I'm a bit confused here, so I'm not sure if this is related, but > emit_move_insn calls rs6000_emit_move with the above 'dst' and 'src', > which calls force_reg(SFmode, (const_int xx)), which is where we get > the REG_EQUAL note: > > (insn 11 10 0 (set (reg:SF 120) > (mem/u/i:SF (lo_sum:SI (reg:SI 121) > (symbol_ref/u:SI ("*.LC0") [flags 0x2])) [0 S4 A32])) > -1 (nil) > (expr_list:REG_EQUAL (const_int 1202908642 [0x47b2ede2]) > (nil))) > > It looks like store_bit_field is at fault by calling the emit_move_insn > with an incompatible source/dest. Is (set (reg:SF) (const_int)) valid > rtl? David had mentioned it was, but now I'm not sure. No, I don't think it's valid RTL; certainly, there is no reason for it to be. David commented: > The rs6000 movsf pattern allows that combination, if reg:SF is a GPR. which it does, by using 'n', but I suspect that's just a workaround for some old bug (perhaps even this one). It's been that way since at least 1997. --Apple-Mail-2--585398830 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-length: 3270 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIGRTCCAv4wggJnoAMCAQICAwyqbjANBgkqhkiG9w0BAQQFADBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwHhcNMDQwNzEyMDAxMzAyWhcNMDUwNzEyMDAxMzAyWjByMRAwDgYD VQQEEwdLZWF0aW5nMRkwFwYDVQQqExBHZW9mZnJleSBGcmFuY2lzMSEwHwYD VQQDExhHZW9mZnJleSBGcmFuY2lzIEtlYXRpbmcxIDAeBgkqhkiG9w0BCQEW EWdlb2Zma0BnZW9mZmsub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAz1axExdjJ+RtQWeSVlPhaB8CZWRAaw9FfzQOuHIrfx8+JYSoK0QS 2hmxIY2Xl+DcjWLrS4E5NLU7c4IT6wf2YgATottkcCPv23CUHpjR6GfsXDEo xYUXJpqGtp2+dQ961w6zO8o9qRJZGQTR+gZMuop/XUy9RsPa5TFduzmqPx+q voa9Zy70u3enROVvPdl4oZcc+xggk1IAfoJ2fFRhEP6RUl+Ndgw/smbKdl5h dB0UHM6uZ/9qYPMiobk6s2BYXS/iQdNcecGIkF6CXpPHGOOhls6GElXCzqgs /xSdYxAmcW/+wQbDep6hWXe/JwQoot8kQfxDzrzGrFX1OlaYFQIDAQABoy4w LDAcBgNVHREEFTATgRFnZW9mZmtAZ2VvZmZrLm9yZzAMBgNVHRMBAf8EAjAA MA0GCSqGSIb3DQEBBAUAA4GBAF5yTt0HOqSmciAIpzK9XiamceHzBDoVNnF4 Hu2g+WjTxYYyg9S+JLVCB0oTlFuLDl7nGhVAiOKd/rI6JoU2ggPUjjsP/JHi 0SX7AlPbJWFQFTdRhQjU/eXx2BzlMRyXmCJjrTMNHvoBaQLjgp4aDN7H1I5d hgIon3Lsg5SNKSD5MIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/ DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoT zyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZ cmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDww OjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFs RnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRow GAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBI jNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8 /a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr3 94fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLj AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMMqm4wCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMDE3MDI0MTI1 WjAjBgkqhkiG9w0BCQQxFgQUsKw2Plo1i95fNWPDu+f/02O3Vr8weAYJKwYB BAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyqbjB6BgsqhkiG9w0BCRACCzFroGkw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMMqm4wDQYJKoZIhvcNAQEBBQAEggEALBXnBtDALCARa0XD TnJ2RaU/BU/2AE6heF2ohzfQkCzPiK1eM1Hi5muBP8l/K4LOspME1DBSgvWC 6N2UYdGKWNfQEXalUyoNVzQTKdaMGtyelKbxF43+qWQ2HjoxPZOQHrxhNsaX H3BlajjG0s4W4OuMY0UOXTif6IZ2kJNBWuHDn7Cn3ob1IpwfdKJs8zDhV8RL +IjMzy0jGniahZmAo6Z6IzEJzqDTceR5cmj8k1IzeGvHvKyNLPrpi7IfHAt9 5O4NLbSTn+0k/f6LutclD6qFgL9EVp94VJuactV72VSrv6AC/+3ReouhRlIh ZgoMTlbQNF0+VRam3GHdgte2YwAAAAAAAA== --Apple-Mail-2--585398830--