From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74249 invoked by alias); 2 Jul 2019 11:20: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 74238 invoked by uid 89); 2 Jul 2019 11:20:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-lf1-f68.google.com Received: from mail-lf1-f68.google.com (HELO mail-lf1-f68.google.com) (209.85.167.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 02 Jul 2019 11:20:50 +0000 Received: by mail-lf1-f68.google.com with SMTP id u10so11062679lfm.12 for ; Tue, 02 Jul 2019 04:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=CJclXJ/MREIse/fp98ZQhRC/p2OTaLq/AJXaTTs5nlg=; b=eLXDooYkdsdUBt501S2pN6lZuo3t7e3NgGk/CcbGGiWKJKbWQoRtpa9rFg88NcsZ0r CcWGs1lx35WttOn4wcvuKOVstgHOGpefOla3s034gNqUBJGfKCEcQUIJSbVy84IJPNre mh5VsEUNNVc4uVZro2z3I//wfRiNdXjPrjZu7DsGQbs18p8Z+goqe8fJHWiwuYchbEAS GXUYNmoIu3sT1LGNzP9iRk/x6eNkzUTr6WEheke232sDeu0QmDufJmLW/CtgoQVxKjAh fH3pZDdAlZOSeUyNTUncc+eE4jAP0A/xyFj1IKb1IrNJYElggSo1KOZlWUzHXCX16FMQ wydg== MIME-Version: 1.0 References: In-Reply-To: From: Prathamesh Kulkarni Date: Tue, 02 Jul 2019 11:20:00 -0000 Message-ID: Subject: Re: [SVE] [fwprop] PR88833 - Redundant moves for WHILELO-based loops To: Prathamesh Kulkarni , gcc Patches , Segher Boessenkool , Richard Sandiford Content-Type: multipart/mixed; boundary="000000000000b70b27058cb0efb2" X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00131.txt.bz2 --000000000000b70b27058cb0efb2 Content-Type: text/plain; charset="UTF-8" Content-length: 9376 On Wed, 26 Jun 2019 at 23:45, Richard Sandiford wrote: > > Prathamesh Kulkarni writes: > > On Wed, 26 Jun 2019 at 16:05, Richard Sandiford > > wrote: > >> > >> Prathamesh Kulkarni writes: > >> > On Tue, 25 Jun 2019 at 20:05, Richard Sandiford > >> > wrote: > >> >> > >> >> Prathamesh Kulkarni writes: > >> >> > On Mon, 24 Jun 2019 at 21:41, Prathamesh Kulkarni > >> >> > wrote: > >> >> >> > >> >> >> On Mon, 24 Jun 2019 at 19:51, Richard Sandiford > >> >> >> wrote: > >> >> >> > > >> >> >> > Prathamesh Kulkarni writes: > >> >> >> > > @@ -1415,6 +1460,19 @@ forward_propagate_into (df_ref use) > >> >> >> > > if (!def_set) > >> >> >> > > return false; > >> >> >> > > > >> >> >> > > + if (reg_prop_only > >> >> >> > > + && !REG_P (SET_SRC (def_set)) > >> >> >> > > + && !REG_P (SET_DEST (def_set))) > >> >> >> > > + return false; > >> >> >> > > >> >> >> > This should be: > >> >> >> > > >> >> >> > if (reg_prop_only > >> >> >> > && (!REG_P (SET_SRC (def_set)) || !REG_P (SET_DEST (def_set)))) > >> >> >> > return false; > >> >> >> > > >> >> >> > so that we return false if either operand isn't a register. > >> >> >> Oops, sorry about that -:( > >> >> >> > > >> >> >> > > + > >> >> >> > > + /* Allow propagations into a loop only for reg-to-reg copies, since > >> >> >> > > + replacing one register by another shouldn't increase the cost. */ > >> >> >> > > + > >> >> >> > > + if (DF_REF_BB (def)->loop_father != DF_REF_BB (use)->loop_father > >> >> >> > > + && !REG_P (SET_SRC (def_set)) > >> >> >> > > + && !REG_P (SET_DEST (def_set))) > >> >> >> > > + return false; > >> >> >> > > >> >> >> > Same here. > >> >> >> > > >> >> >> > OK with that change, thanks. > >> >> >> Thanks for the review, will make the changes and commit the patch > >> >> >> after re-testing. > >> >> > Hi, > >> >> > Testing the patch showed following failures on 32-bit x86: > >> >> > > >> >> > Executed from: g++.target/i386/i386.exp > >> >> > g++:g++.target/i386/pr88152.C scan-assembler-not vpcmpgt|vpcmpeq|vpsra > >> >> > Executed from: gcc.target/i386/i386.exp > >> >> > gcc:gcc.target/i386/pr66768.c scan-assembler add*.[ \t]%gs: > >> >> > gcc:gcc.target/i386/pr90178.c scan-assembler-times xorl[\\t > >> >> > ]*\\%eax,[\\t ]*%eax 1 > >> >> > > >> >> > The failure of pr88152.C is also seen on x86_64. > >> >> > > >> >> > For pr66768.c, and pr90178.c, forwprop replaces register which is > >> >> > volatile and frame related respectively. > >> >> > To avoid that, the attached patch, makes a stronger constraint that > >> >> > src and dest should be a register > >> >> > and not have frame_related or volatil flags set, which is checked in > >> >> > usable_reg_p(). > >> >> > Which avoids the failures for both the cases. > >> >> > Does it look OK ? > >> >> > >> >> That's not the reason it's a bad transform. In both cases we're > >> >> propagating r2 <- r1 even though > >> >> > >> >> (a) r1 dies in the copy and > >> >> (b) fwprop can't replace all uses of r2, because some have multiple > >> >> definitions > >> >> > >> >> This has the effect of making both values live in cases where only one > >> >> was previously. > >> >> > >> >> In the case of pr66768.c, fwprop2 is undoing the effect of > >> >> cse.c:canon_reg, which tries to pick the best register to use > >> >> (see cse.c:make_regs_eqv). fwprop1 makes the same change, > >> >> and made it even before the patch, but the cse.c choice should win. > >> >> > >> >> A (hopefully) conservative fix would be to propagate the copy only if > >> >> both registers have a single definition, which you can test with: > >> >> > >> >> (DF_REG_DEF_COUNT (regno) == 1 > >> >> && !bitmap_bit_p (DF_LR_OUT (ENTRY_BLOCK_PTR_FOR_FN (m_fn)), regno)) > >> >> > >> >> In that case, fwprop should see all uses of the destination, and should > >> >> be able to replace it in all cases with the source. > >> > Ah I see, thanks for the explanation! > >> > The above check works to resolve the failure. > >> > IIUC, !bitmap_bit_p (...) above checks that reg isn't used uninitialized ? > >> > >> Right. > >> > >> >> > For g++.target/i386/pr88152.C, the issue is that after the patch, > >> >> > forwprop1 does following propagation (in f10) which wasn't done > >> >> > before: > >> >> > > >> >> > In insn 10, replacing > >> >> > (unspec:SI [ > >> >> > (reg:V2DF 91) > >> >> > ] UNSPEC_MOVMSK) > >> >> > with (unspec:SI [ > >> >> > (subreg:V2DF (reg:V2DI 90) 0) > >> >> > ] UNSPEC_MOVMSK) > >> >> > > >> >> > This later defeats combine because insn 9 gets deleted. > >> >> > Without patch, the following combination takes place: > >> >> > > >> >> > Trying 7 -> 9: > >> >> > 7: r90:V2DI=r89:V2DI>r93:V2DI > >> >> > REG_DEAD r93:V2DI > >> >> > REG_DEAD r89:V2DI > >> >> > 9: r91:V2DF=r90:V2DI#0 > >> >> > REG_DEAD r90:V2DI > >> >> > Successfully matched this instruction: > >> >> > (set (subreg:V2DI (reg:V2DF 91) 0) > >> >> > (gt:V2DI (reg:V2DI 89) > >> >> > (reg:V2DI 93))) > >> >> > allowing combination of insns 7 and 9 > >> >> > > >> >> > and then: > >> >> > Trying 6, 9 -> 10: > >> >> > 6: r89:V2DI=const_vector > >> >> > 9: r91:V2DF#0=r89:V2DI>r93:V2DI > >> >> > REG_DEAD r89:V2DI > >> >> > REG_DEAD r93:V2DI > >> >> > 10: r87:SI=unspec[r91:V2DF] 43 > >> >> > REG_DEAD r91:V2DF > >> >> > Successfully matched this instruction: > >> >> > (set (reg:SI 87) > >> >> > (unspec:SI [ > >> >> > (lt:V2DF (reg:V2DI 93) > >> >> > (const_vector:V2DI [ > >> >> > (const_int 0 [0]) repeated x2 > >> >> > ])) > >> >> > ] UNSPEC_MOVMSK)) > >> >> > >> >> Eh? lt:*V2DF*? Does that mean that it's 0 for false and an all-1 NaN > >> >> for true? > >> > Well looking at .optimized dump: > >> > > >> > vector(2) long int _2; > >> > vector(2) double _3; > >> > int _6; > >> > signed long _7; > >> > long int _8; > >> > signed long _9; > >> > long int _10; > >> > > >> > [local count: 1073741824]: > >> > _7 = BIT_FIELD_REF ; > >> > _8 = _7 < 0 ? -1 : 0; > >> > _9 = BIT_FIELD_REF ; > >> > _10 = _9 < 0 ? -1 : 0; > >> > _2 = {_8, _10}; > >> > _3 = VIEW_CONVERT_EXPR<__m128d>(_2); > >> > _6 = __builtin_ia32_movmskpd (_3); [tail call] > >> > return _6; > >> > > >> > So AFAIU, we're using -1 for representing true and 0 for false > >> > and casting -1 (literally) to double would change it's value to -NaN ? > >> > >> Exactly. And for -ffinite-math-only, we might as well then fold the > >> condition to false. :-) > >> > >> IMO rtl condition results have to have integral modes and not folding > >> (subreg:V2DF (lt:V2DI ...) 0) is the correct behaviour. So I think this > >> is just a latent bug and shouldn't hold up the patch. > >> > >> I'm not sure whether: > >> > >> reinterpret_cast<__m128d> (a > ...) > >> > >> is something we expect users to write, or whether it was just > >> included for completeness. > > I will report the issue and commit after re-testing patch. > > Thanks a lot for the helpful reviews! > > Since it seems FP comparison results are OK, I guess it needs to be > fixed after all. I think the problem is that the simplification > is only done by gen_lowpart_for_combine: > > /* If X is a comparison operator, rewrite it in a new mode. This > probably won't match, but may allow further simplifications. */ > else if (COMPARISON_P (x)) > return gen_rtx_fmt_ee (GET_CODE (x), omode, XEXP (x, 0), XEXP (x, 1)); > > and triggers via expand_field_assignment when the subreg is on the lhs > of the SET. For it to work for a general subreg on the rhs, it probably > needs to be moved from here to simplify_subreg. > > We'll need to be careful about the conditions under which it > happens though. The above doesn't for example check whether > the new mode has the same number of elements as the original, > so could generate things like: > > (gt:V4SF (reg:V2DI X) (reg:V2DI Y)) > > for: > > (set (reg:V2DI res) (gt:V2DI (reg:V2DI X) (reg:V2DI Y))) > (subreg:V4SF (reg:V2DI res) 0) > > I think most code would expect the result of a comparison to have the > same number of elements as the inputs and could ICE if they don't, > so I don't think it's up to the target to decide whether mismatches > are OK. (But there again, I thought that last time. :-)) > > We'd also need to check the element sizes, since e.g. a lowpart > (subreg:V2HI ...) of a V2SI comparison isn't the same as a V2HI > comparison. Hi Richard, Thanks for the detailed suggestions and sorry for late response, for some reason, I missed this email earlier -;( With the changes to simplify_subreg, the test doesn't regress anymore. IIUC it does the following change: (subreg:V2DF (lt:V2DI (reg:V2DI 93) (const_vector 0))) -> (lt:V2DF (reg:V2DI 93) (const_vector 0)) which allowed the 6, 7 -> 10 combination which was failing earlier. Does the attached version look OK ? Testing in progress. Thanks, Prathamesh > > Thanks, > Richard --000000000000b70b27058cb0efb2 Content-Type: application/x-patch; name="pr88833-11.diff" Content-Disposition: attachment; filename="pr88833-11.diff" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jxlpwcrz0 Content-length: 9647 ZGlmZiAtLWdpdCBhL2djYy9md3Byb3AuYyBiL2djYy9md3Byb3AuYwppbmRl eCA0NTcwM2ZlNWYwMS4uZTZmMzc1MjcxOTIgMTAwNjQ0Ci0tLSBhL2djYy9m d3Byb3AuYworKysgYi9nY2MvZndwcm9wLmMKQEAgLTQ0OCw2ICs0NDgsMTgg QEAgZW51bSB7CiAgIFBSX09QVElNSVpFX0ZPUl9TUEVFRCA9IDQKIH07CiAK Ky8qIENoZWNrIHRoYXQgWCBoYXMgYSBzaW5nbGUgZGVmLiAgKi8KKworc3Rh dGljIGJvb2wKK3JlZ19zaW5nbGVfZGVmX3AgKHJ0eCB4KQoreworICBpZiAo IVJFR19QICh4KSkKKyAgICByZXR1cm4gZmFsc2U7CisKKyAgaW50IHJlZ25v ID0gUkVHTk8gKHgpOworICByZXR1cm4gKERGX1JFR19ERUZfQ09VTlQgKHJl Z25vKSA9PSAxCisJICAmJiAhYml0bWFwX2JpdF9wIChERl9MUl9PVVQgKEVO VFJZX0JMT0NLX1BUUl9GT1JfRk4gKGNmdW4pKSwgcmVnbm8pKTsKK30KIAog LyogUmVwbGFjZSBhbGwgb2NjdXJyZW5jZXMgb2YgT0xEIGluICpQWCB3aXRo IE5FVyBhbmQgdHJ5IHRvIHNpbXBsaWZ5IHRoZQogICAgcmVzdWx0aW5nIGV4 cHJlc3Npb24uICBSZXBsYWNlICpQWCB3aXRoIGEgbmV3IFJUTCBleHByZXNz aW9uIGlmIGFuCkBAIC01NDcsNiArNTU5LDU0IEBAIHByb3BhZ2F0ZV9ydHhf MSAocnR4ICpweCwgcnR4IG9sZF9ydHgsIHJ0eCBuZXdfcnR4LCBpbnQgZmxh Z3MpCiAJICB0ZW0gPSBzaW1wbGlmeV9nZW5fc3VicmVnIChtb2RlLCBvcDAs IEdFVF9NT0RFIChTVUJSRUdfUkVHICh4KSksCiAJCQkJICAgICBTVUJSRUdf QllURSAoeCkpOwogCX0KKworICAgICAgZWxzZQorCXsKKwkgIHJ0dmVjIHZl YzsKKwkgIHJ0dmVjIG5ld3ZlYzsKKwkgIGNvbnN0IGNoYXIgKmZtdCA9IEdF VF9SVFhfRk9STUFUIChjb2RlKTsKKwkgIHJ0eCBvcDsKKworCSAgZm9yIChp bnQgaSA9IDA7IGZtdFtpXTsgaSsrKQorCSAgICBzd2l0Y2ggKGZtdFtpXSkK KwkgICAgICB7CisJICAgICAgY2FzZSAnRSc6CisJCXZlYyA9IFhWRUMgKHgs IGkpOworCQluZXd2ZWMgPSB2ZWM7CisJCWZvciAoaW50IGogPSAwOyBqIDwg R0VUX05VTV9FTEVNICh2ZWMpOyBqKyspCisJCSAgeworCQkgICAgb3AgPSBS VFZFQ19FTFQgKHZlYywgaik7CisJCSAgICB2YWxpZF9vcHMgJj0gcHJvcGFn YXRlX3J0eF8xICgmb3AsIG9sZF9ydHgsIG5ld19ydHgsIGZsYWdzKTsKKwkJ ICAgIGlmIChvcCAhPSBSVFZFQ19FTFQgKHZlYywgaikpCisJCSAgICAgIHsK KwkJCWlmIChuZXd2ZWMgPT0gdmVjKQorCQkJICB7CisJCQkgICAgbmV3dmVj ID0gc2hhbGxvd19jb3B5X3J0dmVjICh2ZWMpOworCQkJICAgIGlmICghdGVt KQorCQkJICAgICAgdGVtID0gc2hhbGxvd19jb3B5X3J0eCAoeCk7CisJCQkg ICAgWFZFQyAodGVtLCBpKSA9IG5ld3ZlYzsKKwkJCSAgfQorCQkJUlRWRUNf RUxUIChuZXd2ZWMsIGopID0gb3A7CisJCSAgICAgIH0KKwkJICB9CisJICAg ICAgICBicmVhazsKKworCSAgICAgIGNhc2UgJ2UnOgorCQlpZiAoWEVYUCAo eCwgaSkpCisJCSAgeworCQkgICAgb3AgPSBYRVhQICh4LCBpKTsKKwkJICAg IHZhbGlkX29wcyAmPSBwcm9wYWdhdGVfcnR4XzEgKCZvcCwgb2xkX3J0eCwg bmV3X3J0eCwgZmxhZ3MpOworCQkgICAgaWYgKG9wICE9IFhFWFAgKHgsIGkp KQorCQkgICAgICB7CisJCQlpZiAoIXRlbSkKKwkJCSAgdGVtID0gc2hhbGxv d19jb3B5X3J0eCAoeCk7CisJCQlYRVhQICh0ZW0sIGkpID0gb3A7CisJCSAg ICAgIH0KKwkJICB9CisJICAgICAgICBicmVhazsKKwkgICAgICB9CisJfQor CiAgICAgICBicmVhazsKIAogICAgIGNhc2UgUlRYX09CSjoKQEAgLTEzNzAs MTAgKzE0MzAsMTEgQEAgZm9yd2FyZF9wcm9wYWdhdGVfYW5kX3NpbXBsaWZ5 IChkZl9yZWYgdXNlLCBydHhfaW5zbiAqZGVmX2luc24sIHJ0eCBkZWZfc2V0 KQogCiAvKiBHaXZlbiBhIHVzZSBVU0Ugb2YgYW4gaW5zbiwgaWYgaXQgaGFz IGEgc2luZ2xlIHJlYWNoaW5nCiAgICBkZWZpbml0aW9uLCB0cnkgdG8gZm9y d2FyZCBwcm9wYWdhdGUgaXQgaW50byB0aGF0IGluc24uCi0gICBSZXR1cm4g dHJ1ZSBpZiBjZmcgY2xlYW51cCB3aWxsIGJlIG5lZWRlZC4gICovCisgICBS ZXR1cm4gdHJ1ZSBpZiBjZmcgY2xlYW51cCB3aWxsIGJlIG5lZWRlZC4KKyAg IFJFR19QUk9QX09OTFkgaXMgdHJ1ZSBpZiB3ZSBzaG91bGQgb25seSBwcm9w YWdhdGUgcmVnaXN0ZXIgY29waWVzLiAgKi8KIAogc3RhdGljIGJvb2wKLWZv cndhcmRfcHJvcGFnYXRlX2ludG8gKGRmX3JlZiB1c2UpCitmb3J3YXJkX3By b3BhZ2F0ZV9pbnRvIChkZl9yZWYgdXNlLCBib29sIHJlZ19wcm9wX29ubHkg PSBmYWxzZSkKIHsKICAgZGZfcmVmIGRlZjsKICAgcnR4X2luc24gKmRlZl9p bnNuLCAqdXNlX2luc247CkBAIC0xMzk0LDEwICsxNDU1LDYgQEAgZm9yd2Fy ZF9wcm9wYWdhdGVfaW50byAoZGZfcmVmIHVzZSkKICAgaWYgKERGX1JFRl9J U19BUlRJRklDSUFMIChkZWYpKQogICAgIHJldHVybiBmYWxzZTsKIAotICAv KiBEbyBub3QgcHJvcGFnYXRlIGxvb3AgaW52YXJpYW50IGRlZmluaXRpb25z IGluc2lkZSB0aGUgbG9vcC4gICovCi0gIGlmIChERl9SRUZfQkIgKGRlZikt Pmxvb3BfZmF0aGVyICE9IERGX1JFRl9CQiAodXNlKS0+bG9vcF9mYXRoZXIp Ci0gICAgcmV0dXJuIGZhbHNlOwotCiAgIC8qIENoZWNrIGlmIHRoZSB1c2Ug aXMgc3RpbGwgcHJlc2VudCBpbiB0aGUgaW5zbiEgICovCiAgIHVzZV9pbnNu ID0gREZfUkVGX0lOU04gKHVzZSk7CiAgIGlmIChERl9SRUZfRkxBR1MgKHVz ZSkgJiBERl9SRUZfSU5fTk9URSkKQEAgLTE0MTUsNiArMTQ3MiwxOSBAQCBm b3J3YXJkX3Byb3BhZ2F0ZV9pbnRvIChkZl9yZWYgdXNlKQogICBpZiAoIWRl Zl9zZXQpCiAgICAgcmV0dXJuIGZhbHNlOwogCisgIGlmIChyZWdfcHJvcF9v bmx5CisgICAgICAmJiAoIXJlZ19zaW5nbGVfZGVmX3AgKFNFVF9TUkMgKGRl Zl9zZXQpKQorCSAgfHwgIXJlZ19zaW5nbGVfZGVmX3AgKFNFVF9ERVNUIChk ZWZfc2V0KSkpKQorICAgIHJldHVybiBmYWxzZTsKKworICAvKiBBbGxvdyBw cm9wYWdhdGlvbnMgaW50byBhIGxvb3Agb25seSBmb3IgcmVnLXRvLXJlZyBj b3BpZXMsIHNpbmNlCisgICAgIHJlcGxhY2luZyBvbmUgcmVnaXN0ZXIgYnkg YW5vdGhlciBzaG91bGRuJ3QgaW5jcmVhc2UgdGhlIGNvc3QuICAqLworCisg IGlmIChERl9SRUZfQkIgKGRlZiktPmxvb3BfZmF0aGVyICE9IERGX1JFRl9C QiAodXNlKS0+bG9vcF9mYXRoZXIKKyAgICAgICYmICghcmVnX3NpbmdsZV9k ZWZfcCAoU0VUX1NSQyAoZGVmX3NldCkpCisJICB8fCAhcmVnX3NpbmdsZV9k ZWZfcCAoU0VUX0RFU1QgKGRlZl9zZXQpKSkpCisgICAgcmV0dXJuIGZhbHNl OworCiAgIC8qIE9ubHkgdHJ5IG9uZSBraW5kIG9mIHByb3BhZ2F0aW9uLiAg SWYgdHdvIGFyZSBwb3NzaWJsZSwgd2UnbGwKICAgICAgZG8gaXQgb24gdGhl IGZvbGxvd2luZyBpdGVyYXRpb25zLiAgKi8KICAgaWYgKGZvcndhcmRfcHJv cGFnYXRlX2FuZF9zaW1wbGlmeSAodXNlLCBkZWZfaW5zbiwgZGVmX3NldCkK QEAgLTE0ODMsNyArMTU1Myw3IEBAIGdhdGVfZndwcm9wICh2b2lkKQogfQog CiBzdGF0aWMgdW5zaWduZWQgaW50Ci1md3Byb3AgKHZvaWQpCitmd3Byb3Ag KGJvb2wgZndwcm9wX2FkZHJfcCkKIHsKICAgdW5zaWduZWQgaTsKIApAQCAt MTUwMiwxMSArMTU3MiwxNiBAQCBmd3Byb3AgKHZvaWQpCiAKICAgICAgIGRm X3JlZiB1c2UgPSBERl9VU0VTX0dFVCAoaSk7CiAgICAgICBpZiAodXNlKQot CWlmIChERl9SRUZfVFlQRSAodXNlKSA9PSBERl9SRUZfUkVHX1VTRQotCSAg ICB8fCBERl9SRUZfQkIgKHVzZSktPmxvb3BfZmF0aGVyID09IE5VTEwKLQkg ICAgLyogVGhlIG91dGVyIG1vc3QgbG9vcCBpcyBub3QgcmVhbGx5IGEgbG9v cC4gICovCi0JICAgIHx8IGxvb3Bfb3V0ZXIgKERGX1JFRl9CQiAodXNlKS0+ bG9vcF9mYXRoZXIpID09IE5VTEwpCi0JICBmb3J3YXJkX3Byb3BhZ2F0ZV9p bnRvICh1c2UpOworCXsKKwkgIGlmIChERl9SRUZfVFlQRSAodXNlKSA9PSBE Rl9SRUZfUkVHX1VTRQorCSAgICAgIHx8IERGX1JFRl9CQiAodXNlKS0+bG9v cF9mYXRoZXIgPT0gTlVMTAorCSAgICAgIC8qIFRoZSBvdXRlciBtb3N0IGxv b3AgaXMgbm90IHJlYWxseSBhIGxvb3AuICAqLworCSAgICAgIHx8IGxvb3Bf b3V0ZXIgKERGX1JFRl9CQiAodXNlKS0+bG9vcF9mYXRoZXIpID09IE5VTEwp CisJICAgIGZvcndhcmRfcHJvcGFnYXRlX2ludG8gKHVzZSwgZndwcm9wX2Fk ZHJfcCk7CisKKwkgIGVsc2UgaWYgKGZ3cHJvcF9hZGRyX3ApCisJICAgIGZv cndhcmRfcHJvcGFnYXRlX2ludG8gKHVzZSwgZmFsc2UpOworCX0KICAgICB9 CiAKICAgZndwcm9wX2RvbmUgKCk7CkBAIC0xNTM3LDcgKzE2MTIsNyBAQCBw dWJsaWM6CiAKICAgLyogb3B0X3Bhc3MgbWV0aG9kczogKi8KICAgdmlydHVh bCBib29sIGdhdGUgKGZ1bmN0aW9uICopIHsgcmV0dXJuIGdhdGVfZndwcm9w ICgpOyB9Ci0gIHZpcnR1YWwgdW5zaWduZWQgaW50IGV4ZWN1dGUgKGZ1bmN0 aW9uICopIHsgcmV0dXJuIGZ3cHJvcCAoKTsgfQorICB2aXJ0dWFsIHVuc2ln bmVkIGludCBleGVjdXRlIChmdW5jdGlvbiAqKSB7IHJldHVybiBmd3Byb3Ag KGZhbHNlKTsgfQogCiB9OyAvLyBjbGFzcyBwYXNzX3J0bF9md3Byb3AKIApA QCAtMTU0OSwzMyArMTYyNCw2IEBAIG1ha2VfcGFzc19ydGxfZndwcm9wIChn Y2M6OmNvbnRleHQgKmN0eHQpCiAgIHJldHVybiBuZXcgcGFzc19ydGxfZndw cm9wIChjdHh0KTsKIH0KIAotc3RhdGljIHVuc2lnbmVkIGludAotZndwcm9w X2FkZHIgKHZvaWQpCi17Ci0gIHVuc2lnbmVkIGk7Ci0KLSAgZndwcm9wX2lu aXQgKCk7Ci0KLSAgLyogR28gdGhyb3VnaCBhbGwgdGhlIHVzZXMuICBkZl91 c2VzX2NyZWF0ZSB3aWxsIGNyZWF0ZSBuZXcgb25lcyBhdCB0aGUKLSAgICAg ZW5kLCBhbmQgd2UnbGwgZ28gdGhyb3VnaCB0aGVtIGFzIHdlbGwuICAqLwot ICBmb3IgKGkgPSAwOyBpIDwgREZfVVNFU19UQUJMRV9TSVpFICgpOyBpKysp Ci0gICAgewotICAgICAgaWYgKCFwcm9wYWdhdGlvbnNfbGVmdCkKLQlicmVh azsKLQotICAgICAgZGZfcmVmIHVzZSA9IERGX1VTRVNfR0VUIChpKTsKLSAg ICAgIGlmICh1c2UpCi0JaWYgKERGX1JFRl9UWVBFICh1c2UpICE9IERGX1JF Rl9SRUdfVVNFCi0JICAgICYmIERGX1JFRl9CQiAodXNlKS0+bG9vcF9mYXRo ZXIgIT0gTlVMTAotCSAgICAvKiBUaGUgb3V0ZXIgbW9zdCBsb29wIGlzIG5v dCByZWFsbHkgYSBsb29wLiAgKi8KLQkgICAgJiYgbG9vcF9vdXRlciAoREZf UkVGX0JCICh1c2UpLT5sb29wX2ZhdGhlcikgIT0gTlVMTCkKLQkgIGZvcndh cmRfcHJvcGFnYXRlX2ludG8gKHVzZSk7Ci0gICAgfQotCi0gIGZ3cHJvcF9k b25lICgpOwotICByZXR1cm4gMDsKLX0KLQogbmFtZXNwYWNlIHsKIAogY29u c3QgcGFzc19kYXRhIHBhc3NfZGF0YV9ydGxfZndwcm9wX2FkZHIgPQpAQCAt MTYwMCw3ICsxNjQ4LDcgQEAgcHVibGljOgogCiAgIC8qIG9wdF9wYXNzIG1l dGhvZHM6ICovCiAgIHZpcnR1YWwgYm9vbCBnYXRlIChmdW5jdGlvbiAqKSB7 IHJldHVybiBnYXRlX2Z3cHJvcCAoKTsgfQotICB2aXJ0dWFsIHVuc2lnbmVk IGludCBleGVjdXRlIChmdW5jdGlvbiAqKSB7IHJldHVybiBmd3Byb3BfYWRk ciAoKTsgfQorICB2aXJ0dWFsIHVuc2lnbmVkIGludCBleGVjdXRlIChmdW5j dGlvbiAqKSB7IHJldHVybiBmd3Byb3AgKHRydWUpOyB9CiAKIH07IC8vIGNs YXNzIHBhc3NfcnRsX2Z3cHJvcF9hZGRyCiAKZGlmZiAtLWdpdCBhL2djYy9z aW1wbGlmeS1ydHguYyBiL2djYy9zaW1wbGlmeS1ydHguYwppbmRleCA4OWE0 NmE5MzNmYS4uNzliZDBjZmJkMjggMTAwNjQ0Ci0tLSBhL2djYy9zaW1wbGlm eS1ydHguYworKysgYi9nY2Mvc2ltcGxpZnktcnR4LmMKQEAgLTY2OTcsNiAr NjY5NywxOSBAQCBzaW1wbGlmeV9zdWJyZWcgKG1hY2hpbmVfbW9kZSBvdXRl cm1vZGUsIHJ0eCBvcCwKIAl9CiAgICAgfQogCisgIC8qIElmIG9wIGlzIGEg dmVjdG9yIGNvbXBhcmlzb24gb3BlcmF0b3IsIHJld3JpdGUgaXQgaW4gYSBu ZXcgbW9kZS4KKyAgICAgVGhpcyBwcm9iYWJseSB3b24ndCBtYXRjaCwgYnV0 IG1heSBhbGxvdyBmdXJ0aGVyIHNpbXBsaWZpY2F0aW9ucy4KKyAgICAgQWxz byBjaGVjayBpZiBudW1iZXIgb2YgZWxlbWVudHMgYW5kIHNpemUgb2YgZWFj aCBlbGVtZW50CisgICAgIG1hdGNoIGZvciBvdXRlcm1vZGUgYW5kIGlubmVy bW9kZS4gICovCisKKyAgaWYgKENPTVBBUklTT05fUCAob3ApCisgICAgICAm JiBWRUNUT1JfTU9ERV9QIChvdXRlcm1vZGUpCisgICAgICAmJiBWRUNUT1Jf TU9ERV9QIChpbm5lcm1vZGUpCisgICAgICAmJiAoa25vd25fZXEgKEdFVF9N T0RFX05VTklUUyAob3V0ZXJtb2RlKSwgR0VUX01PREVfTlVOSVRTIChpbm5l cm1vZGUpKSkKKyAgICAgICYmIChrbm93bl9lcSAoR0VUX01PREVfVU5JVF9T SVpFIChvdXRlcm1vZGUpLAorCQkgICAgR0VUX01PREVfVU5JVF9TSVpFIChp bm5lcm1vZGUpKSkpCisgICAgcmV0dXJuIGdlbl9ydHhfZm10X2VlIChHRVRf Q09ERSAob3ApLCBvdXRlcm1vZGUsIFhFWFAgKG9wLCAwKSwgWEVYUCAob3As IDEpKTsKKwogICByZXR1cm4gTlVMTF9SVFg7CiB9CiAKZGlmZiAtLWdpdCBh L2djYy90ZXN0c3VpdGUvZ2ZvcnRyYW4uZGcvcHI4ODgzMy5mOTAgYi9nY2Mv dGVzdHN1aXRlL2dmb3J0cmFuLmRnL3ByODg4MzMuZjkwCm5ldyBmaWxlIG1v ZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAwMDAwLi4yMjRlNmNlNWYzZAotLS0g L2Rldi9udWxsCisrKyBiL2djYy90ZXN0c3VpdGUvZ2ZvcnRyYW4uZGcvcHI4 ODgzMy5mOTAKQEAgLTAsMCArMSw5IEBACishIHsgZGctZG8gYXNzZW1ibGUg eyB0YXJnZXQgYWFyY2g2NF9hc21fc3ZlX29rIH0gfQorISB7IGRnLW9wdGlv bnMgIi1PMyAtbWFyY2g9YXJtdjguMi1hK3N2ZSAtLXNhdmUtdGVtcHMiIH0K Kworc3Vicm91dGluZSBmb28oeCkKKyAgcmVhbCA6OiB4KDEwMCkKKyAgeCA9 IHggKyAxMAorZW5kIHN1YnJvdXRpbmUgZm9vCisKKyEgeyBkZy1maW5hbCB7 IHNjYW4tYXNzZW1ibGVyIHtcdHdoaWxlbG9cdHBbMC05XStcLnMsIHd6ciwg KHdbMC05XSspLipcdHdoaWxlbG9cdHBbMC05XStcLnMsIHdbMC05XSssIFwx fSB9IH0K --000000000000b70b27058cb0efb2--