From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47757 invoked by alias); 19 Dec 2015 15:37:53 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 47739 invoked by uid 89); 19 Dec 2015 15:37:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=Based, superset, humor, 64910 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 19 Dec 2015 15:37:51 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 454753297 for ; Sat, 19 Dec 2015 15:37:50 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-83.phx2.redhat.com [10.3.113.83]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBJFbnUE002025 for ; Sat, 19 Dec 2015 10:37:49 -0500 From: Jeff Law Subject: [RFA][PATCH][PR tree-optimization/64910] x86 backend improvement To: gcc-patches Message-ID: <567579CD.6000200@redhat.com> Date: Sat, 19 Dec 2015 15:37:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------000801080102070206050905" X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg01944.txt.bz2 This is a multi-part message in MIME format. --------------000801080102070206050905 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-length: 3287 This patch addresses a deficiency found when testing a patch to fix undesirable gimple code created by reassociation (pr64910). Based on what I've seen from a code generation standpoint before/after this patch, I would say it's highly likely this is fixing a regression in gcc-5. [ This is a piece of 64910 -- essentially it avoids regressing code generation when the fix for 64910 is applied. ] combine.c::make_extraction will query the backend for the correct modes to use for field extractions. Essentially it looks at the backend's extraction pattern. In 4.9 for x86 we had: (define_expand "extzv" [(set (match_operand:SI 0 "register_operand") (zero_extract:SI (match_operand 1 "ext_register_operand") (match_operand:SI 2 "const8_operand") (match_operand:SI 3 "const8_operand")))] make_extraction looks at the modes of the various parts of the zero_extract rtx and uses it to create a suitable zero_extract expression & operands. If the rtx/operand has no mode, word_mode will be used. Note carefully the mode of the zero-extract -- SImode in this case. Anyway, the result of make_extraction is embedded into other patterns like this: (set (flags) (compare (zero_extract:MODE ...) (const_int 0)) Which will be then passed to recog to try and match a backend pattern. Again in 4.9 we have: (define_insn "*testqi_ext_3" [(set (reg FLAGS_REG) (compare (zero_extract:SWI48 (match_operand 0 "nonimmediate_operand" "rm") (match_operand:SWI48 1 "const_int_operand") (match_operand:SWI48 2 "const_int_operand")) (const_int 0)))] So note how the testqi_ext_3 pattern's modes (SWI48, ie, SI/DI) are a strict superset of those in the extzv expander for the zero_extract rtx (SI). That's all fine and good. However, if we look at the trunk (or gcc-5) we have: (define_expand "extzv" [(set (match_operand:SWI248 0 "register_operand") (zero_extract:SWI248 (match_operand:SWI248 1 "register_operand") (match_operand:SI 2 "const_int_operand") (match_operand:SI 3 "const_int_operand")))] And (define_insn "*testqi_ext_3" [(set (reg FLAGS_REG) (compare (zero_extract:SWI48 (match_operand 0 "nonimmediate_operand" "rm") (match_operand 1 "const_int_operand" "n") (match_operand 2 "const_int_operand" "n")) (const_int 0)))] Note how the mode of the zero_extract in the expander allows HImode (SWI248), but the mode of the zero_extract in testqi_ext_3 does not allow HImode (SWI48). So make_extraction will create (set (flags) (compare (zero_extract:HI (...) (const_int 0)) But testqi_ext_3 does not support HImode on the zero_extract and the pattern doesn't match which cripples combine's ability to create these insns. Fixing this results in consistently better code by eliminating setup code for bit tests. It's quite pervasive in GCC itself. This has been bootstrapped and regression tested on x86_64-linux-gnu, with and without the rest of the fix for 64910. The test has been tested on x86 and x86-64. OK for the trunk? --------------000801080102070206050905 Content-Type: text/plain; charset=UTF-8; name="patch" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="patch" Content-length: 2831 ZGlmZiAtLWdpdCBhL2djYy9DaGFuZ2VMb2cgYi9nY2MvQ2hhbmdlTG9nCmlu ZGV4IDFjYWEwNzYuLmU2ZWMzY2QgMTAwNjQ0Ci0tLSBhL2djYy9DaGFuZ2VM b2cKKysrIGIvZ2NjL0NoYW5nZUxvZwpAQCAtMSwzICsxLDggQEAKKzIwMTUt MTItMTkgIEplZmYgTGF3ICA8bGF3QHJlZGhhdC5jb20+CisKKwlQUiB0cmVl LW9wdGltaXphdGlvbi82NDkxMAorCSogY29uZmlnL2kzODYvaTM4Ni5tZCAo dGVzdHFpX2V4dF8zKTogQWxsb3cgSEltb2RlLgorCiAyMDE1LTEyLTE4ICBK ZWZmIExhdyAgPGxhd0ByZWRoYXQuY29tPgogCiAJUFIgcnRsLW9wdGltaXph dGlvbi80OTg0NwpkaWZmIC0tZ2l0IGEvZ2NjL2NvbmZpZy9pMzg2L2kzODYu bWQgYi9nY2MvY29uZmlnL2kzODYvaTM4Ni5tZAppbmRleCA0OWIyMjE2Li5l ODE3OGYzIDEwMDY0NAotLS0gYS9nY2MvY29uZmlnL2kzODYvaTM4Ni5tZAor KysgYi9nY2MvY29uZmlnL2kzODYvaTM4Ni5tZApAQCAtNzg2OCw3ICs3ODY4 LDcgQEAKIDs7IENvbWJpbmUgbGlrZXMgdG8gZm9ybSBiaXQgZXh0cmFjdGlv bnMgZm9yIHNvbWUgdGVzdHMuICBIdW1vciBpdC4KIChkZWZpbmVfaW5zbiAi KnRlc3RxaV9leHRfMyIKICAgWyhzZXQgKHJlZyBGTEFHU19SRUcpCi0JKGNv bXBhcmUgKHplcm9fZXh0cmFjdDpTV0k0OAorCShjb21wYXJlICh6ZXJvX2V4 dHJhY3Q6U1dJMjQ4CiAJCSAgIChtYXRjaF9vcGVyYW5kIDAgIm5vbmltbWVk aWF0ZV9vcGVyYW5kIiAicm0iKQogCQkgICAobWF0Y2hfb3BlcmFuZCAxICJj b25zdF9pbnRfb3BlcmFuZCIgIm4iKQogCQkgICAobWF0Y2hfb3BlcmFuZCAy ICJjb25zdF9pbnRfb3BlcmFuZCIgIm4iKSkKZGlmZiAtLWdpdCBhL2djYy90 ZXN0c3VpdGUvQ2hhbmdlTG9nIGIvZ2NjL3Rlc3RzdWl0ZS9DaGFuZ2VMb2cK aW5kZXggNTczMjZkMS4uMTQzYzczYyAxMDA2NDQKLS0tIGEvZ2NjL3Rlc3Rz dWl0ZS9DaGFuZ2VMb2cKKysrIGIvZ2NjL3Rlc3RzdWl0ZS9DaGFuZ2VMb2cK QEAgLTEsMyArMSw4IEBACisyMDE1LTEyLTE5ICBKZWZmIExhdyAgPGxhd0By ZWRoYXQuY29tPgorCisJUFIgdHJlZS1vcHRpbWl6YXRpb24vNjQ5MTAKKwkq IGdjYy50YXJnZXQvaTM4Ni9iaXR0ZXN0LmM6IE5ldyB0ZXN0LgorCiAyMDE1 LTEyLTE4ICBKZWZmIExhdyAgPGxhd0ByZWRoYXQuY29tPgogCiAJUFIgcnRs LW9wdGltaXphdGlvbi80OTg0NwpkaWZmIC0tZ2l0IGEvZ2NjL3Rlc3RzdWl0 ZS9nY2MudGFyZ2V0L2kzODYvYml0dGVzdC5jIGIvZ2NjL3Rlc3RzdWl0ZS9n Y2MudGFyZ2V0L2kzODYvYml0dGVzdC5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0 CmluZGV4IDAwMDAwMDAuLjdiN2NlOWUKLS0tIC9kZXYvbnVsbAorKysgYi9n Y2MvdGVzdHN1aXRlL2djYy50YXJnZXQvaTM4Ni9iaXR0ZXN0LmMKQEAgLTAs MCArMSwyMiBAQAorLyogeyBkZy1kbyBjb21waWxlIH0gKi8KKy8qIHsgZGct b3B0aW9ucyAiLU8yIiB9ICovCisKK2V4dGVybiBpbnQgZGJnX2NudCAodm9p ZCk7CisKK3N0cnVjdCBmdW5jdGlvbgoreworICB1bnNpZ25lZCBpbnQgY2Fs bHNfc2V0am1wOjE7Cit9OworZXh0ZXJuIHN0cnVjdCBmdW5jdGlvbiAqY2Z1 bjsKK3Vuc2lnbmVkIGNoYXIKK2dhdGVfcnRsX2Nwcm9wICh2b2lkKQorewor ICByZXR1cm4gIShjZnVuICsgMCktPmNhbGxzX3NldGptcCAmJiBkYmdfY250 ICgpOworfQorCisvKiBUaGlzIHNob3VsZCBiZSBpbXBsZW1lbnRhYmxlIHdp dGhvdXQgcGVyZm9ybWluZyBhIGJpdG1hc2sgYXMgd2UgY2FuCisgICBqdXN0 IHVzZSBhIHRlc3QgaW1tLG1lbS4gIFNvIGluc3RydWN0aW9ucyB3aGljaCBs b2FkIHRoZSBvYmplY3QgZnJvbQorICAgbWVtb3J5IGFuZCBtYXNrIG9mZiBi aXRzIGFyZSB1bm5lY2Vzc2FyeS4gIEluIHRoZW9yeSB3ZSBjYW4ganVzdCBj b3VudAorICAgdGhlIG1vdmUtd2l0aC1leHRlbnNpb24sIGFuZCBhbmQgdGVz dGIgaW5zdHJ1Y3Rpb25zLiAgVGhlcmUgc2hvdWxkIGJlCisgICBvbmx5IG9u ZS4gICovCisvKiB7IGRnLWZpbmFsIHsgc2Nhbi1hc3NlbWJsZXItdGltZXMg Im1vdnpibHxhbmR8dGVzdGIiIDEgeyB0YXJnZXQgeyBpPzg2LSotKiB4ODZf NjQtKi0qfSB9IH0gfSAqLwo= --------------000801080102070206050905--