From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29268 invoked by alias); 6 Jul 2014 14:24:09 -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 29225 invoked by uid 89); 6 Jul 2014 14:24:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail3-relais-sop.national.inria.fr Received: from mail3-relais-sop.national.inria.fr (HELO mail3-relais-sop.national.inria.fr) (192.134.164.104) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Sun, 06 Jul 2014 14:24:01 +0000 Received: from stedding.saclay.inria.fr ([193.55.250.194]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 06 Jul 2014 16:23:39 +0200 Received: from glisse (helo=localhost) by stedding.saclay.inria.fr with local-esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X3nLu-0003ch-Vo; Sun, 06 Jul 2014 16:23:39 +0200 Date: Sun, 06 Jul 2014 14:24:00 -0000 From: Marc Glisse To: Jeff Law cc: gcc-patches@gcc.gnu.org Subject: Re: update address taken: don't drop clobbers In-Reply-To: <53B1BB13.50901@redhat.com> Message-ID: References: <53B1BB13.50901@redhat.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1678220433-1404656618=:13753" X-SW-Source: 2014-07/txt/msg00376.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1678220433-1404656618=:13753 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-length: 2493 On Mon, 30 Jun 2014, Jeff Law wrote: > On 06/28/14 16:33, Marc Glisse wrote: >> In an earlier version of the patch, I was using >> get_or_create_ssa_default_def (cfun, sym); >> (I was reusing the same variable). This passed bootstrap+testsuite on >> all languages except for ada. Indeed, the compiler wanted to coalesce >> several SSA_NAMEs, including those new ones, in out-of-ssa, but >> couldn't. > And that's what you need to delve deeper into. Why did it refuse to > coalesce? > > As long as the lifetimes do not overlap, then coalescing should have worked. What is the lifetime of an SSA_NAME with a default definition? The way we handle it now, we start from the uses and go back to all blocks that can reach one of the uses, since there is no defining statement where we could stop (intuitively we should stop where the clobber was, if not earlier). This huge lifetime makes it very likely for such an SSA_NAME to conflict with others. And if an abnormal phi is involved, and thus we must coalesce, there is a problem. The patch attached (it should probably use ssa_undefined_value_p with a new extra argument to say whether we care about partially-undefined) makes the lifetime of undefined local variables empty and lets the original patch work with: def = get_or_create_ssa_default_def (cfun, sym); instead of creating a new variable. However, I am not convinced reusing the same variable is necessarily the best thing. For warnings, we can create a new variable with the same name (with .1 added by gcc at the end) and copy the location info (I am not doing that yet), so little is lost. A new variable expresses more clearly that the value it holds is random crap. If I reuse the same variable, the SRA patch doesn't warn because SRA explicitly sets TREE_NO_WARNING (this can probably be changed, but that's starting to be a lot of changes). Creating a new variable is also more general. When reading *ssa_name after *ssa_name={v}{CLOBBER}; or after free(ssa_name); we have no variable to reuse so we will need to create a new undefined variable, and if a variable is global or a PARM_DECL, its default definition is not an undefined value (though it will probably happen in a different pass, so it doesn't have to behave the same). (Side note: we don't seem to have any code to notice that: a=phi b=phi means both phis can be replaced with undefined variables.) Do you have any advice on the right direction? -- Marc Glisse --8323329-1678220433-1404656618=:13753 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=p14 Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: inline; filename=p14 Content-length: 2684 SW5kZXg6IGdjYy90cmVlLXNzYS1saXZlLmMNCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCi0tLSBnY2MvdHJlZS1zc2EtbGl2ZS5jCShyZXZpc2lvbiAyMTIz MDYpDQorKysgZ2NjL3RyZWUtc3NhLWxpdmUuYwkod29ya2luZyBjb3B5KQ0K QEAgLTEwODYsMjAgKzEwODYsMjggQEAgc2V0X3Zhcl9saXZlX29uX2VudHJ5 ICh0cmVlIHNzYV9uYW1lLCB0cg0KICAgaWYgKHN0bXQpDQogICAgIHsNCiAg ICAgICBkZWZfYmIgPSBnaW1wbGVfYmIgKHN0bXQpOw0KICAgICAgIC8qIE1h cmsgZGVmcyBpbiBsaXZlb3V0IGJpdG1hcCB0ZW1wb3JhcmlseS4gICovDQog ICAgICAgaWYgKGRlZl9iYikNCiAJYml0bWFwX3NldF9iaXQgKCZsaXZlLT5s aXZlb3V0W2RlZl9iYi0+aW5kZXhdLCBwKTsNCiAgICAgfQ0KICAgZWxzZQ0K ICAgICBkZWZfYmIgPSBFTlRSWV9CTE9DS19QVFJfRk9SX0ZOIChjZnVuKTsN CiANCisgIC8qIEFuIHVuZGVmaW5lZCBsb2NhbCB2YXJpYWJsZSBkb2VzIG5v dCBuZWVkIHRvIGJlIHZlcnkgYWxpdmUuICAqLw0KKyAgaWYgKFNTQV9OQU1F X0lTX0RFRkFVTFRfREVGIChzc2FfbmFtZSkpDQorICAgIHsNCisgICAgICB0 cmVlIHZhciA9IFNTQV9OQU1FX1ZBUiAoc3NhX25hbWUpOw0KKyAgICAgIGlm ICh2YXIgJiYgVFJFRV9DT0RFICh2YXIpID09IFZBUl9ERUNMICYmICFpc19n bG9iYWxfdmFyICh2YXIpKQ0KKwlyZXR1cm47DQorICAgIH0NCisNCiAgIC8q IFZpc2l0IGVhY2ggdXNlIG9mIFNTQV9OQU1FIGFuZCBpZiBpdCBpc24ndCBp biB0aGUgc2FtZSBibG9jayBhcyB0aGUgZGVmLA0KICAgICAgYWRkIGl0IHRv IHRoZSBsaXN0IG9mIGxpdmUgb24gZW50cnkgYmxvY2tzLiAgKi8NCiAgIEZP Ul9FQUNIX0lNTV9VU0VfRkFTVCAodXNlLCBpbW1faXRlciwgc3NhX25hbWUp DQogICAgIHsNCiAgICAgICBnaW1wbGUgdXNlX3N0bXQgPSBVU0VfU1RNVCAo dXNlKTsNCiAgICAgICBiYXNpY19ibG9jayBhZGRfYmxvY2sgPSBOVUxMOw0K IA0KICAgICAgIGlmIChnaW1wbGVfY29kZSAodXNlX3N0bXQpID09IEdJTVBM RV9QSEkpDQogICAgICAgICB7DQogCSAgLyogVXNlcyBpbiBQSEkncyBhcmUg Y29uc2lkZXJlZCB0byBiZSBsaXZlIGF0IGV4aXQgb2YgdGhlIFNSQyBibG9j aw0KQEAgLTE0MjIsMjAgKzE0MzAsMjcgQEAgdmVyaWZ5X2xpdmVfb25fZW50 cnkgKHRyZWVfbGl2ZV9pbmZvX3AgbA0KIAkJCSAgZnByaW50ZiAoc3RkZXJy LCAiXG4iKTsNCiAJCQl9DQogCQkgICAgICBlbHNlDQogCQkJZnByaW50ZiAo c3RkZXJyLCAiIGFuZCB0aGVyZSBpcyBubyBkZWZhdWx0IGRlZi5cbiIpOw0K IAkJICAgIH0NCiAJCX0NCiAJICAgIH0NCiAJICBlbHNlDQogCSAgICBpZiAo ZCA9PSB2YXIpDQogCSAgICAgIHsNCisJCS8qIEFuIHVuZGVmaW5lZCBsb2Nh bCB2YXJpYWJsZSBkb2VzIG5vdCBuZWVkIHRvIGJlIHZlcnkNCisJCSAgIGFs aXZlLiAgKi8NCisJCXRyZWUgcmVhbF92YXIgPSBTU0FfTkFNRV9WQVIgKHZh cik7DQorCQlpZiAocmVhbF92YXIgJiYgVFJFRV9DT0RFIChyZWFsX3Zhcikg PT0gVkFSX0RFQ0wNCisJCSAgICAmJiAhaXNfZ2xvYmFsX3ZhciAocmVhbF92 YXIpKQ0KKwkJICBjb250aW51ZTsNCisNCiAJCS8qIFRoZSBvbmx5IHdheSB0 aGlzIHZhciBzaG91bGRuJ3QgYmUgbWFya2VkIGxpdmUgb24gZW50cnkgaXMN CiAJCSAgIGlmIGl0IG9jY3VycyBpbiBhIFBISSBhcmd1bWVudCBvZiB0aGUg YmxvY2suICAqLw0KIAkJc2l6ZV90IHo7DQogCQlib29sIG9rID0gZmFsc2U7 DQogCQlnaW1wbGVfc3RtdF9pdGVyYXRvciBnc2k7DQogCQlmb3IgKGdzaSA9 IGdzaV9zdGFydF9waGlzIChlLT5kZXN0KTsNCiAJCSAgICAgIWdzaV9lbmRf cCAoZ3NpKSAmJiAhb2s7DQogCQkgICAgIGdzaV9uZXh0ICgmZ3NpKSkNCiAJ CSAgew0KIAkJICAgIGdpbXBsZSBwaGkgPSBnc2lfc3RtdCAoZ3NpKTsNCg== --8323329-1678220433-1404656618=:13753--