From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12120 invoked by alias); 15 Jul 2018 22:19:51 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 12100 invoked by uid 89); 15 Jul 2018 22:19:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=p.s, P.S, UD:P.S, temporaries X-HELO: userp2120.oracle.com Received: from userp2120.oracle.com (HELO userp2120.oracle.com) (156.151.31.85) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 15 Jul 2018 22:19:48 +0000 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w6FMIumL132917; Sun, 15 Jul 2018 22:19:46 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=corp-2018-07-02; bh=YZ5TJMbioMMQH3SstaeCIKWYyq+NyfD8zip4z69vSWw=; b=5R0rmJRVvTGy7OEmW0vQQFnYEa9m4lqNPRqx5OqHP6pLnnNGXYKM7kjLuIAfgGVdenP5 5OWvZ2zVCTvZdffEnIyl8oaQmqqh7fjG/c602ZEQUWuYw60ekBVBfvQkWELFLf9LSpIY X/fpPJVmiZOjmRSI3A5InR7Mmg91d0N9awVZai5cbaPn9i9vAB8iZxDeOo2n+pAZrve6 YaZGzSFYUE/4rM1gWh3YFcQR8DhU2IvOgUiS80R221oPCcv4H3Ftv12srW61ZAAKsW26 7e76MG1N4NpQS8Mk0nC8hqLyKPnYOvCQH0wOY8rE7/1smp7j2ob0h/ia6qeCqXU1ET4g ug== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2k7a3jj8yc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 15 Jul 2018 22:19:46 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w6FMJiNl004831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 15 Jul 2018 22:19:45 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w6FMJivZ003886; Sun, 15 Jul 2018 22:19:44 GMT Received: from [10.39.212.240] (/10.39.212.240) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 15 Jul 2018 15:19:43 -0700 Subject: Re: Understanding tree_swap_operands_p wrt SSA name versions To: Richard Biener , Jeff Law Cc: GCC Development References: <5b1a8e4b-c0c5-69f7-1800-605e0b844acb@oracle.com> <226ee5ff-ac66-e8a4-7a67-a07a92eaebbb@redhat.com> <165C3FA6-E1CC-454D-8A2A-9DA9348301D8@gmail.com> <80a30b2c-8b23-f4ed-aa8c-275a554ec9ff@oracle.com> <23cf65ef-2312-b13b-5696-604ca15c7d8e@redhat.com> From: Michael Ploujnikov Openpgp: preference=signencrypt Message-ID: <45e0a278-9323-b7f4-26d6-1270d369e7b2@oracle.com> Date: Sun, 15 Jul 2018 22:19:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gNnj4wr7DPv3dKm6XTp4UMYyBVGTh88ST" X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00210.txt.bz2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gNnj4wr7DPv3dKm6XTp4UMYyBVGTh88ST Content-Type: multipart/mixed; boundary="KNEhpJAN0VXIHy81FXh5sfXE2MJiyyxiO"; protected-headers="v1" From: Michael Ploujnikov To: Richard Biener , Jeff Law Cc: GCC Development Message-ID: <45e0a278-9323-b7f4-26d6-1270d369e7b2@oracle.com> Subject: Re: Understanding tree_swap_operands_p wrt SSA name versions References: <5b1a8e4b-c0c5-69f7-1800-605e0b844acb@oracle.com> <226ee5ff-ac66-e8a4-7a67-a07a92eaebbb@redhat.com> <165C3FA6-E1CC-454D-8A2A-9DA9348301D8@gmail.com> <80a30b2c-8b23-f4ed-aa8c-275a554ec9ff@oracle.com> <23cf65ef-2312-b13b-5696-604ca15c7d8e@redhat.com> In-Reply-To: --KNEhpJAN0VXIHy81FXh5sfXE2MJiyyxiO Content-Type: multipart/mixed; boundary="------------4FFBE6AE8710B81FB2A94B3D" Content-Language: en-US This is a multi-part message in MIME format. --------------4FFBE6AE8710B81FB2A94B3D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 8199 On 2018-07-04 04:52 AM, Richard Biener wrote: > On Tue, Jul 3, 2018 at 9:09 PM Jeff Law wrote: >> >> On 07/03/2018 11:55 AM, Michael Ploujnikov wrote: >>> On 2018-07-03 12:46 PM, Richard Biener wrote: >>>> On July 3, 2018 4:56:57 PM GMT+02:00, Michael Ploujnikov wrote: >>>>> On 2018-06-20 04:23 AM, Richard Biener wrote: >>>>>> On Wed, Jun 20, 2018 at 7:31 AM Jeff Law wrote: >>>>>>> >>>>>>> On 06/19/2018 12:30 PM, Michael Ploujnikov wrote: >>>>>>>> Hi everyone, >>>>>>>> >>>>>>>> (I hope this is the right place to ask, if not my apologies; please >>>>>>>> point me in the right direction) >>>>>>>> >>>>>>>> I'm trying to get a better understanding of the following part in >>>>>>>> tree_swap_operands_p(): >>>>>>>> >>>>>>>> /* It is preferable to swap two SSA_NAME to ensure a canonical >>>>> form >>>>>>>> for commutative and comparison operators. Ensuring a >>>>> canonical >>>>>>>> form allows the optimizers to find additional redundancies >>>>> without >>>>>>>> having to explicitly check for both orderings. */ >>>>>>>> if (TREE_CODE (arg0) =3D=3D SSA_NAME >>>>>>>> && TREE_CODE (arg1) =3D=3D SSA_NAME >>>>>>>> && SSA_NAME_VERSION (arg0) > SSA_NAME_VERSION (arg1)) >>>>>>>> return 1; >>>>>>>> >>>>>>>> My questions in no particular order: It looks like this was added >>>>> in >>>>>>>> 2004. I couldn't find any info other than what's in the >>>>> corresponding >>>>>>>> commit (cc0bdf913) so I'm wondering if the canonical form/order >>>>> still >>>>>>>> relevant/needed today? Does the ordering have to be done based on >>>>> the >>>>>>>> name versions specifically? Or can it be based on something more >>>>>>>> intrinsic to the input source code rather than a GCC internal >>>>> value, eg: >>>>>>>> would alphabetic sort order of the variable names be a reasonable >>>>>>>> replacement? >>>>>>> Canonicalization is still important and useful. >>>>>> >>>>>> Indeed. >>>>>> >>>>>>> However, canonicalizing on SSA_NAMEs is problematical due to the way >>>>> we >>>>>>> recycle nodes and re-pack them. >>>>>> >>>>>> In the past we made sure to not disrupt order - hopefully that didn't >>>>> change >>>>>> so the re-packing shoudln't invaidate previous canonicalization: >>>>>> >>>>>> static void >>>>>> release_free_names_and_compact_live_names (function *fun) >>>>>> { >>>>>> ... >>>>>> /* And compact the SSA number space. We make sure to not change >>>>> the >>>>>> relative order of SSA versions. */ >>>>>> for (i =3D 1, j =3D 1; i < fun->gimple_df->ssa_names->length (); += +i) >>>>>> { >>>>>> >>>>>> >>>>>>> I think defining additional rules for canonicalization prior to >>>>> using >>>>>>> SSA_NAME_VERSION as the fallback would be looked upon favorably. >>>>>> >>>>>> I don't see a good reason to do that, it will be harder to spot >>>>> canonicalization >>>>>> issues and it will take extra compile-time. >>>>>> >>>>>>> Note however, that many of the _DECL nodes referenced by SSA_NAMEs >>>>> are >>>>>>> temporaries generated by the compiler and do not correspond to any >>>>>>> declared/defined object in the original source. So you'll still >>>>> need >>>>>>> the SSA_NAME_VERSION (or something as stable or better) >>>>> canonicalization >>>>>>> to handle those cases. >>>>>> >>>>>> And not all SSA_NAMEs have underlying _DECL nodes (or IDENTIFIER_NODE >>>>> names). >>>>>> >>>>>> Richard. >>>>>> >>>>>>> Jeff >>>>> >>>>> After a bit more digging I found that insert_phi_nodes inserts PHIs in >>>>> the order of UIDs, which indirectly affects the order of vars in >>>>> old_ssa_names, which in turn affects the order in which >>>>> make_ssa_name_fn >>>>> is called to pick SSA versions from FREE_SSANAMES so in the end >>>>> ordering by SSA_NAME_VERSION's is more or less equivalent to ordering >>>>> by >>>>> UIDs. I'm trying to figure out if there's a way to avoid depending on >>>>> UIDs being ordered in a certain way. So if tree_swap_operands_p stays >>>>> the same I'm wondering if there's some other info available at the >>>>> point >>>>> of insert_phi_nodes that would be a good replacement for UID. From my >>>>> very limited experience with a very small source input, and if I >>>>> understand things correctly, all of the var_infos have a var which is >>>>> DECL_P and thus should have an IDENTIFIER_NODE. Is that true in the >>>>> general case? I don't fully understand what are all the things that >>>>> insert_phi_nodes iterates over. >>>> >>>> Why do you want to remove the dependence on UID ordering? It's pervasi= ve throughout the whole compilation... >>>> >>>> Richard. >>>> >>>>> - Michael >>>> >>> >>> >>> Well, I'm working on a reduction of the number of changes seen with >>> binary diffing (a la https://wiki.debian.org/ReproducibleBuilds) and >>> since current UID assignment is essentially tied to the order of things >>> in the input source code one function's changes can cascade to others >>> (even when they're unchanged). As you said UID dependence is quiet >>> pervasive, and although finding and improving individual cases (such as >>> tree_swap_operands_p) won't make it perfect, I think it will be a step >>> in the positive direction. >>> >>> Also, I have some ideas for a UID assignment scheme that might improve >>> things overall, that I'll try to share after I get back from vacation. >> I'm still not sure what the point is. GIven the same input, you're >> going to get the same output. Using UIDs is deterministic. If the >> input changes, then, yea, sure the output is going to change, but that's >> got to be expected. Just wanted to say thanks for taking the time to answer my questions. My main goal is to make each function's codegen as independent from one another as possible. In other words, source changes to function A shouldn't result in assembly changes for any of the other functions. Example attached. I have a prototype of a UID assignment scheme that handles a lot of cases; I'm just waiting for legal approval before I can share the actual code. In the meantime I'm trying to understand the problem from the bottom up and came across this tree_swap_operands_p case. I'm asking for your expertise as to whether my conclusion (that PHI node UID order dictates the SSA version assignment) is correct. > Yeah, UIDs are likely not the correct handle on this.> You might get > "less" code generation changes when you change sources by > using -fno-toplevel-reorder. Using no-toplevel-reorder didn't help, plus my situation is so general that I can't control the enabled flags. >=20 > I also remember that at one point I facilitated debugging / testcase > reduction by "rounding" UIDs up when starting to process a different > function. Is there a thread about this that you can point me to? I'm curious about the details. P.S. The attached sources can compiled with: gcc-7.3.1 -fno-toplevel-reorder -nostdinc -isystem /usr/lib/gcc/i686-redhat-linux/4.4.6/include -I/builddir/build/BUILD/kernel-2.6.39/linux-2.6.39.i686/arch/x86/include -Iarch/x86/include/generated -Iinclude -include include/generated/autoconf.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -m32 -msoft-float -mregparm=3D3 -freg-struct-return -mpreferred-stack-boundary=3D2 -march=3Di686 -mtune=3Dgeneric -maccumulate-outgoing-args -ffreestanding -fstack-protector -DCONFIG_AS_CFI=3D1 -DCONFIG_AS_CFI_SIGNAL_FRAME=3D1 -DCONFIG_AS_CFI_SECTIONS=3D1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wframe-larger-than=3D1024 -Wno-unused-but-set-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -femit-struct-debug-baseonly -pg -fno-inline-functions-called-once -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO -ftest-coverage -ffunction-sections -fdata-sections -D__DATE__=3D"<{DATE...}>" -D__TIME__=3D"<{TIME}>" '-DKBUILD_STR(s)=3D#s' '-DKBUILD_BASENAME=3DKBUILD_STR(hrtimer)' '-DKBUILD_MODNAME=3DKBUILD_STR(hrtimer)' -c -o /tmp/pre.o /tmp/pre.i - Michael --------------4FFBE6AE8710B81FB2A94B3D Content-Type: text/plain; charset=UTF-8; name="pre.i" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pre.i" Content-length: 1936 dHlwZWRlZiBzaWduZWQgbG9uZyBsb25nIHM2NDsKdW5pb24ga3RpbWUgewog czY0IHR2NjQ7Cn07CnR5cGVkZWYgdW5pb24ga3RpbWUga3RpbWVfdDsKCnN0 cnVjdCB0aW1lcl9saXN0IHsKIHVuc2lnbmVkIGxvbmcgZXhwaXJlczsKIHZv aWQgKCpmdW5jdGlvbikodW5zaWduZWQgbG9uZyk7CiB1bnNpZ25lZCBsb25n IGRhdGE7CiBpbnQgc2xhY2s7Cn07CgpleHRlcm4gdW5zaWduZWQgbG9uZyB2 b2xhdGlsZSBfX2F0dHJpYnV0ZV9fKChzZWN0aW9uKCIuZGF0YSIpKSkgamlm ZmllczsKZXh0ZXJuIGludCBtb2RfdGltZXIoc3RydWN0IHRpbWVyX2xpc3Qg KnRpbWVyLCB1bnNpZ25lZCBsb25nIGV4cGlyZXMpOwpleHRlcm4gdm9pZCB0 aW1lcmZkX2Nsb2NrX3dhc19zZXQodm9pZCk7CmludCBvbl9lYWNoX2NwdSh2 b2lkICpmdW5jLCB2b2lkICppbmZvLCBpbnQgd2FpdCk7Cgp2b2lkIGNsb2Nr X3dhc19zZXQodm9pZCkKewogb25fZWFjaF9jcHUoKCh2b2lkICopMCksICgo dm9pZCAqKTApLCAxKTsKIHRpbWVyZmRfY2xvY2tfd2FzX3NldCgpOwp9Cgpl bnVtIHsKIGZhbHNlID0gMCwKIHRydWUgPSAxCn07CnR5cGVkZWYgX0Jvb2wg Ym9vbDsKCmVudW0gZGVidWdfb2JqX3N0YXRlIHsKIE9ERUJVR19TVEFURV9B Q1RJVkUsCiBPREVCVUdfU1RBVEVfTk9UQVZBSUxBQkxFLAp9OwpleHRlcm4g dm9pZCB3YXJuX3Nsb3dwYXRoX251bGwoY29uc3QgY2hhciAqZmlsZSwgY29u c3QgaW50IGxpbmUpOwppbnQgaHJ0aW1lcl9maXh1cF9hY3RpdmF0ZSh2b2lk ICphZGRyLCBlbnVtIGRlYnVnX29ial9zdGF0ZSBzdGF0ZSkKewogc3dpdGNo IChzdGF0ZSkgewoKIGNhc2UgT0RFQlVHX1NUQVRFX05PVEFWQUlMQUJMRToK ICAoeyBzdGF0aWMgYm9vbCBfX3dhcm5lZDsgaW50IF9fcmV0X3dhcm5fb25j ZSA9ICEhKDEpOyBpZiAoX19idWlsdGluX2V4cGVjdCghIShfX3JldF93YXJu X29uY2UpLCAwKSkgaWYgKCh7IGludCBfX3JldF93YXJuX29uID0gISEoIV9f d2FybmVkKTsgaWYgKF9fYnVpbHRpbl9leHBlY3QoISEoX19yZXRfd2Fybl9v biksIDApKSB3YXJuX3Nsb3dwYXRoX251bGwoImtlcm5lbC9ocnRpbWVyLmMi LCAzODYpOyBfX2J1aWx0aW5fZXhwZWN0KCEhKF9fcmV0X3dhcm5fb24pLCAw KTsgfSkpIF9fd2FybmVkID0gdHJ1ZTsgX19idWlsdGluX2V4cGVjdCghIShf X3JldF93YXJuX29uY2UpLCAwKTsgfSk7CiAgcmV0dXJuIDA7CgogY2FzZSBP REVCVUdfU1RBVEVfQUNUSVZFOgogICh7IGludCBfX3JldF93YXJuX29uID0g ISEoMSk7IGlmIChfX2J1aWx0aW5fZXhwZWN0KCEhKF9fcmV0X3dhcm5fb24p LCAwKSkgd2Fybl9zbG93cGF0aF9udWxsKCJrZXJuZWwvaHJ0aW1lci5jIiwg MzkwKTsgX19idWlsdGluX2V4cGVjdCghIShfX3JldF93YXJuX29uKSwgMCk7 IH0pOwoKIGRlZmF1bHQ6CiAgcmV0dXJuIDA7CiB9Cn0K --------------4FFBE6AE8710B81FB2A94B3D Content-Type: text/plain; charset=UTF-8; name="post.i" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="post.i" Content-length: 2823 dHlwZWRlZiBzaWduZWQgbG9uZyBsb25nIHM2NDsKdW5pb24ga3RpbWUgewog czY0IHR2NjQ7Cn07CnR5cGVkZWYgdW5pb24ga3RpbWUga3RpbWVfdDsKCnN0 cnVjdCB0aW1lcl9saXN0IHsKIHVuc2lnbmVkIGxvbmcgZXhwaXJlczsKIHZv aWQgKCpmdW5jdGlvbikodW5zaWduZWQgbG9uZyk7CiB1bnNpZ25lZCBsb25n IGRhdGE7CiBpbnQgc2xhY2s7Cn07CgpleHRlcm4gdW5zaWduZWQgbG9uZyB2 b2xhdGlsZSBfX2F0dHJpYnV0ZV9fKChzZWN0aW9uKCIuZGF0YSIpKSkgamlm ZmllczsKZXh0ZXJuIGludCBtb2RfdGltZXIoc3RydWN0IHRpbWVyX2xpc3Qg KnRpbWVyLCB1bnNpZ25lZCBsb25nIGV4cGlyZXMpOwpleHRlcm4gdm9pZCB0 aW1lcmZkX2Nsb2NrX3dhc19zZXQodm9pZCk7CmludCBvbl9lYWNoX2NwdSh2 b2lkICpmdW5jLCB2b2lkICppbmZvLCBpbnQgd2FpdCk7CgpleHRlcm4gdm9p ZCBrdGltZV9nZXRfYW5kX3JlYWxfYW5kX3NsZWVwX29mZnNldChrdGltZV90 ICptb25vdG9uaWMsCiAgICAgIGt0aW1lX3QgKnJlYWxfb2Zmc2V0LAogICAg ICBrdGltZV90ICpzbGVlcF9vZmZzZXQpOwoKc3RhdGljIHZvaWQgZG9fY2xv Y2tfd2FzX3NldCh1bnNpZ25lZCBsb25nIGRhdGEpCnsKIG9uX2VhY2hfY3B1 KCgodm9pZCAqKTApLCAoKHZvaWQgKikwKSwgMSk7CiB0aW1lcmZkX2Nsb2Nr X3dhc19zZXQoKTsKfQoKc3RhdGljIHN0cnVjdCB0aW1lcl9saXN0IGNsb2Nr X3dhc19zZXRfdGltZXIgPSB7IC5leHBpcmVzID0gKDApLCAuZnVuY3Rpb24g PSAoZG9fY2xvY2tfd2FzX3NldCksIC5kYXRhID0gKDApLCAuc2xhY2sgPSAt MX07Cgp2b2lkIGNsb2NrX3dhc19zZXQodm9pZCkKewogaWYgKCh7IHVuc2ln bmVkIGxvbmcgX2ZsYWdzOyBkbyB7ICh7IHVuc2lnbmVkIGxvbmcgX19kdW1t eTsgdHlwZW9mKF9mbGFncykgX19kdW1teTI7ICh2b2lkKSgmX19kdW1teSA9 PSAmX19kdW1teTIpOyAxOyB9KTsgX2ZsYWdzID0gMTsgfSB3aGlsZSAoMCk7 ICh7ICh7IHVuc2lnbmVkIGxvbmcgX19kdW1teTsgdHlwZW9mKF9mbGFncykg X19kdW1teTI7ICh2b2lkKSgmX19kdW1teSA9PSAmX19kdW1teTIpOyAxOyB9 KTsgIShfZmxhZ3MgJiAweDAwMDAwMjAwKTsgfSk7IH0pKQogIG1vZF90aW1l cigmY2xvY2tfd2FzX3NldF90aW1lciwgamlmZmllcyk7CiBlbHNlCiAgZG9f Y2xvY2tfd2FzX3NldCgwKTsKfQoKZW51bSB7CiBmYWxzZSA9IDAsCiB0cnVl ID0gMQp9Owp0eXBlZGVmIF9Cb29sIGJvb2w7CgplbnVtIGRlYnVnX29ial9z dGF0ZSB7CiBPREVCVUdfU1RBVEVfQUNUSVZFLAogT0RFQlVHX1NUQVRFX05P VEFWQUlMQUJMRSwKfTsKZXh0ZXJuIHZvaWQgd2Fybl9zbG93cGF0aF9udWxs KGNvbnN0IGNoYXIgKmZpbGUsIGNvbnN0IGludCBsaW5lKTsKaW50IGhydGlt ZXJfZml4dXBfYWN0aXZhdGUodm9pZCAqYWRkciwgZW51bSBkZWJ1Z19vYmpf c3RhdGUgc3RhdGUpCnsKIHN3aXRjaCAoc3RhdGUpIHsKCiBjYXNlIE9ERUJV R19TVEFURV9OT1RBVkFJTEFCTEU6CiAgKHsgc3RhdGljIGJvb2wgX193YXJu ZWQ7IGludCBfX3JldF93YXJuX29uY2UgPSAhISgxKTsgaWYgKF9fYnVpbHRp bl9leHBlY3QoISEoX19yZXRfd2Fybl9vbmNlKSwgMCkpIGlmICgoeyBpbnQg X19yZXRfd2Fybl9vbiA9ICEhKCFfX3dhcm5lZCk7IGlmIChfX2J1aWx0aW5f ZXhwZWN0KCEhKF9fcmV0X3dhcm5fb24pLCAwKSkgd2Fybl9zbG93cGF0aF9u dWxsKCJrZXJuZWwvaHJ0aW1lci5jIiwgMzg2KTsgX19idWlsdGluX2V4cGVj dCghIShfX3JldF93YXJuX29uKSwgMCk7IH0pKSBfX3dhcm5lZCA9IHRydWU7 IF9fYnVpbHRpbl9leHBlY3QoISEoX19yZXRfd2Fybl9vbmNlKSwgMCk7IH0p OwogIHJldHVybiAwOwoKIGNhc2UgT0RFQlVHX1NUQVRFX0FDVElWRToKICAo eyBpbnQgX19yZXRfd2Fybl9vbiA9ICEhKDEpOyBpZiAoX19idWlsdGluX2V4 cGVjdCghIShfX3JldF93YXJuX29uKSwgMCkpIHdhcm5fc2xvd3BhdGhfbnVs bCgia2VybmVsL2hydGltZXIuYyIsIDM5MCk7IF9fYnVpbHRpbl9leHBlY3Qo ISEoX19yZXRfd2Fybl9vbiksIDApOyB9KTsKCiBkZWZhdWx0OgogIHJldHVy biAwOwogfQp9Cg== --------------4FFBE6AE8710B81FB2A94B3D-- --KNEhpJAN0VXIHy81FXh5sfXE2MJiyyxiO-- --gNnj4wr7DPv3dKm6XTp4UMYyBVGTh88ST Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 473 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJbS8h5AAoJEBnHrw6/GfukYasH/0QtM/+ZF3WHoVSZcI897yCz HwS1xv2OMVpMepa3wTD9bEerEFomw6HPY2VHt91jfIiiams+/oKc4a4UHuih5Tzb SW8E6XuZTriz0MgrJTB0/mCBvJLKwD5XUFxG+nHcZnoNIAwA3kiNHhQUaRGnMsjv /1W77j5GB46DwynWaRLVRrJswDA8JOHULszCflPyyTkcmncnnN9IvtHY5FWTBrDv LoSmh9gBVfNuYh3vUBFCWwwIJV3AN9wScLhmb65tijUIAO5JUrI2IdtgMzXMnEd3 UWMSDGHMbpwajGFV4vG9d29dpG7/x9FT6ZQGdXPACuQS9NQ84Hvm2Vq+f4P67us= =73ka -----END PGP SIGNATURE----- --gNnj4wr7DPv3dKm6XTp4UMYyBVGTh88ST--