From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) by sourceware.org (Postfix) with ESMTPS id 90A673858018; Wed, 20 Jan 2021 04:32:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 90A673858018 Received: by mail-vs1-xe34.google.com with SMTP id e15so12396210vsa.0; Tue, 19 Jan 2021 20:32:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0Jq5Ex9OTd1FJs2/YfF/PVeYqgZE0zf1dfDi7Dgbo0I=; b=SC7wzUxpzhVLFDr7g15X4fhz6fjpTUw9nllTvfoGAgT35nQroa20TcQeK51TrQLaqY VJtoOZTNIXN+0f0zOhrOB7g3P6nR/jEFHJn9+n8Gio0+0rysUr0QhR7mabNEa3rNSdwW vmLGn3BP9efqhRsqcHkSl9aEzZp2isnLmstahvzZyKleB1pkEn3yj3HxXKsqJpmwGpTY kclbA9SuqytVXkoFdv68dfrBfM1ocQQfQRAApVsk8GPR19ElyX70FjrBSOkH9vxgnXfu FEwsQh0TaEfomBpnrFooHvX8VYrqGji8VPOV7yZpW1aPDPRQgQmBbVQhwXG/jHcBS5cO 9MwQ== X-Gm-Message-State: AOAM5312TOjLrjyI5Wx/rxR9vyRLZxmL8SqJyp5n13D/ezCs3HdkMyWb qu1+fTCr7Ik5whP3gWM6F8K0JDb6WJMBDagQk6w0XJ5s X-Google-Smtp-Source: ABdhPJxFVlyMwnonCui67lYqyXd4OfW6sw9uov0ejs98kYJ58aGjFtA4uWnxoRZ1tIzee1RbGTVwXJViu/neu5aW5A4= X-Received: by 2002:a67:bb02:: with SMTP id m2mr5137832vsn.57.1611117141816; Tue, 19 Jan 2021 20:32:21 -0800 (PST) MIME-Version: 1.0 References: <20210119144514.GA4020736@tucnak> In-Reply-To: From: Hongtao Liu Date: Wed, 20 Jan 2021 12:35:15 +0800 Message-ID: Subject: Re: [PATCH] [PR rtl/optimization/98694] Fix incorrect optimization by cprop_hardreg. To: Jakub Jelinek via Gcc-patches , Hongtao Liu , ebotcazou@libertysurf.fr, steven@gcc.gnu.org, Jakub Jelinek , Richard Sandiford Content-Type: multipart/mixed; boundary="000000000000ee185405b94d70d4" X-Spam-Status: No, score=-10.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SCC_5_SHORT_WORD_LINES, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2021 04:32:24 -0000 --000000000000ee185405b94d70d4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 20, 2021 at 12:10 AM Richard Sandiford wrote: > > Jakub Jelinek via Gcc-patches writes: > > On Tue, Jan 19, 2021 at 12:38:47PM +0000, Richard Sandiford via Gcc-pat= ches wrote: > >> > actually only the lower 16bits are needed, the original insn is like > >> > > >> > .294.r.ira > >> > (insn 69 68 70 13 (set (reg:HI 96 [ _52 ]) > >> > (subreg:HI (reg:DI 82 [ var_6.0_1 ]) 0)) "test.c":21:23 76 > >> > {*movhi_internal} > >> > (nil)) > >> > (insn 78 75 82 13 (set (reg:V4HI 140 [ _283 ]) > >> > (vec_duplicate:V4HI (truncate:HI (subreg:SI (reg:HI 96 [ _52 > >> > ]) 0)))) 1412 {*vec_dupv4hi} > >> > (nil)) > >> > > >> > .295r.reload > >> > (insn 69 68 70 13 (set (reg:HI 5 di [orig:96 _52 ] [96]) > >> > (reg:HI 68 k0 [orig:82 var_6.0_1 ] [82])) "test.c":21:23 76 > >> > {*movhi_internal} > >> > (nil)) > >> > (insn 489 75 78 13 (set (reg:SI 22 xmm2 [297]) > >> > (reg:SI 5 di [orig:96 _52 ] [96])) 75 {*movsi_internal} > >> > (nil)) > >> > (insn 78 489 490 13 (set (reg:V4HI 20 xmm0 [orig:140 _283 ] [140]) > >> > (vec_duplicate:V4HI (truncate:HI (reg:SI 22 xmm2 [297])))) > >> > 1412 {*vec_dupv4hi} > >> > (nil)) > >> > > >> > and insn 489 is created by lra/reload which seems ok for the sequenc= e, > >> > but problemistic with considering the logic of hardreg_cprop. > >> > >> It looks OK even with the regcprop behaviour though: > >> > >> - insn 69 defines only the low 16 bits of di, > >> - insn 489 defines only the low 16 bits of xmm2, but copies bits 16-31 > >> too (with unknown contents) > >> - insn 78 uses only the low 16 bits of xmm2 (the unknown contents > >> introduced by insn 489 are truncated away) > >> > >> So where do bits 16-31 become significant? What goes wrong if they're > >> not zero? > > > > The k0 register is initialized I believe with > > (insn 20 2 21 2 (set (reg:DI 68 k0 [orig:82 var_6.0_1 ] [82]) > > (mem/c:DI (symbol_ref:DI ("var_6") [flags 0x40] ) [3 var_6+0 S8 A64])) "pr98694.C":21:10 74 {*movdi_intern= al} > > (nil)) > > and so it contains all 64-bits, and then the code sometimes uses all th= e > > bits, sometimes just the low 16-bits and sometimes low 32-bits of that > > value. > > (insn 69 68 70 12 (set (reg:HI 5 di [orig:96 _52 ] [96]) > > (reg:HI 68 k0 [orig:82 var_6.0_1 ] [82])) "pr98694.C":27:23 76 = {*movhi_internal} > > (nil)) > > (insn 74 73 75 12 (set (reg:SI 36 r8 [orig:149 _52 ] [149]) > > (zero_extend:SI (reg:HI 68 k0 [orig:82 var_6.0_1 ] [82]))) 144 = {*zero_extendhisi2} > > (nil)) > > (insn 489 75 78 12 (set (reg:SI 22 xmm2 [297]) > > (reg:SI 5 di [orig:96 _52 ] [96])) 75 {*movsi_internal} > > (nil)) > > (insn 78 489 490 12 (set (reg:V4HI 20 xmm0 [orig:140 _283 ] [140]) > > (vec_duplicate:V4HI (truncate:HI (reg:SI 22 xmm2 [297])))) 1412= {*vec_dupv4hi} > > (expr_list:REG_DEAD (reg:SI 22 xmm2 [297]) > > (nil))) > > are examples when it uses only the low 16 bits from that, and > > (insn 487 72 73 12 (set (reg:SI 1 dx [148]) > > (reg:SI 68 k0 [orig:82 var_6.0_1 ] [82])) 75 {*movsi_internal} > > (nil)) > > > > (insn 85 84 491 13 (set (reg:SI 37 r9 [orig:86 _11 ] [86]) > > (reg:SI 68 k0 [orig:82 var_6.0_1 ] [82])) "pr98694.C":28:14 75 = {*movsi_internal} > > (nil)) > > > > (insn 491 85 88 13 (set (reg:SI 3 bx [299]) > > (reg:SI 68 k0 [orig:82 var_6.0_1 ] [82])) 75 {*movsi_internal} > > (nil)) > > (insn 88 491 89 13 (set (reg:CCNO 17 flags) > > (compare:CCNO (reg:SI 3 bx [299]) > > (const_int 0 [0]))) 7 {*cmpsi_ccno_1} > > (expr_list:REG_DEAD (reg:SI 3 bx [299]) > > (nil))) > > > > (insn 457 499 460 33 (set (reg:SI 39 r11 [orig:86 _11 ] [86]) > > (reg:SI 37 r9 [orig:86 _11 ] [86])) "pr98694.C":35:36 75 {*movs= i_internal} > > (expr_list:REG_DEAD (reg:SI 37 r9 [orig:86 _11 ] [86]) > > (nil))) > > are examples where it uses low 32-bits from k0. > > So the > > (insn 457 499 460 33 (set (reg:SI 39 r11 [orig:86 _11 ] [86]) > > - (reg:SI 37 r9 [orig:86 _11 ] [86])) "pr98694.C":35:36 75 {*mov= si_internal} > > - (expr_list:REG_DEAD (reg:SI 37 r9 [orig:86 _11 ] [86]) > > + (reg:SI 22 xmm2 [orig:86 _11 ] [86])) "pr98694.C":35:36 75 {*m= ovsi_internal} > > + (expr_list:REG_DEAD (reg:SI 22 xmm2 [orig:86 _11 ] [86]) > > (nil))) > > cprop_hardreg change indeed looks bogus, while xmm2 has SImode, it hold= s > > only the low 16-bits of the value and has the upper bits undefined, whi= le r9 > > it is replacing had all of the low 32-bits well defined. > > Ah, ok, thanks for the extra context. > > So AIUI the problem when recording xmm2<-di isn't just: > > [A] partial_subreg_p (vd->e[sr].mode, GET_MODE (src)) > > but also that: > > [B] partial_subreg_p (vd->e[sr].mode, vd->e[vd->e[sr].oldest_regno].mode= ) > > For example, all registers in this sequence can be part of the same chain= : > > (set (reg:HI R1) (reg:HI R0)) > (set (reg:SI R2) (reg:SI R1)) // [A] > (set (reg:DI R3) (reg:DI R2)) // [A] > (set (reg:SI R4) (reg:SI R[0-3])) > (set (reg:HI R5) (reg:HI R[0-4])) > > But: > > (set (reg:SI R1) (reg:SI R0)) > (set (reg:HI R2) (reg:HI R1)) > (set (reg:SI R3) (reg:SI R2)) // [A] && [B] > > is problematic because it dips below the precision of the oldest regno > and then increases again. > > When this happens, I guess we have two choices: > > (1) what the patch does: treat R3 as the start of a new chain. > (2) pretend that the copy occured in vd->e[sr].mode instead > (i.e. copy vd->e[sr].mode to vd->e[dr].mode) > > I guess (2) would need to be subject to REG_CAN_CHANGE_MODE_P. > Maybe the optimisation provided by (2) compared to (1) isn't common > enough to be worth the complication. > > I think we should test [B] as well as [A] though. The pass is set > up to do some quite elaborate mode changes and I think rejecting > [A] on its own would make some of the other code redundant. > It also feels like it should be a seperate =E2=80=9Cif=E2=80=9D or =E2=80= =9Celse if=E2=80=9D, > with its own comment. > Update patch. > Thanks, > Richard --=20 BR, Hongtao --000000000000ee185405b94d70d4 Content-Type: text/x-patch; charset="US-ASCII"; name="0001-PR-rtl-optimization-98694-Fix-incorrect-optimization_V2.patch" Content-Disposition: attachment; filename="0001-PR-rtl-optimization-98694-Fix-incorrect-optimization_V2.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kk4xmjmt0 RnJvbSBhNTJiM2M4YTkwYTBiZjZjYmRhOGNlODZkOTljODJjNjE4Mjg2M2E3IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBsaXVob25ndCA8aG9uZ3Rhby5saXVAaW50ZWwuY29tPgpEYXRl OiBNb24sIDE4IEphbiAyMDIxIDE2OjU1OjMyICswODAwClN1YmplY3Q6IFtQQVRDSF0gW1BSIHJ0 bC9vcHRpbWl6YXRpb24vOTg2OTRdIEZpeCBpbmNvcnJlY3Qgb3B0aW1pemF0aW9uIGJ5CiBjcHJv cF9oYXJkcmVnLgoKSWYgU1JDIGhhZCBiZWVuIGFzc2lnbmVkIGEgbW9kZSBuYXJyb3dlciB0aGFu IHRoZSBjb3B5LCB3ZSBjYW4ndCBsaW5rCkRFU1QgaW50byB0aGUgY2hhaW4gZXZlbiB0aGV5IGhh dmUgc2FtZQpoYXJkX3JlZ25vX25yZWdzKGkuZS4gSEltb2RlL1NJbW9kZSBpbiBpMzg2IGJhY2tl bmQpLgoKaS5lCiAgICAgICAga21vdncgICAlazAsICVlZGkKICAgICAgICB2bW92ZCAgICVlZGks ICV4bW0yCgl2cHNodWZsdyAgICAgICAgJDAsICV4bW0yLCAleG1tMAogICAgICAgIGttb3Z3ICAg JWswLCAlcjhkCiAgICAgICAga21vdmQgICAlazAsICVyOWQKLi4uCi0JIG1vdmwgJXI5ZCwgJXIx MWQKKwkgdm1vdmQgJXhtbTIsICVyMTFkCgpnY2MvQ2hhbmdlTG9nOgoKCVBSIHJ0bC1vcHRpbWl6 YXRpb24vOTg2OTQKCSogcmVnY3Byb3AuYyAoY29weV92YWx1ZSk6IElmIFNSQyBoYWQgYmVlbiBh c3NpZ25lZCBhIG1vZGUKCW5hcnJvd2VyIHRoYW4gdGhlIGNvcHksIHdlIGNhbid0IGxpbmsgREVT VCBpbnRvIHRoZSBjaGFpbiBldmVuCgl0aGV5IGhhdmUgc2FtZSBoYXJkX3JlZ25vX25yZWdzKGku ZS4gSEltb2RlL1NJbW9kZSBpbiBpMzg2CgliYWNrZW5kKS4KCmdjYy90ZXN0c3VpdGUvQ2hhbmdl TG9nOgoKCVBSIHJ0bC1vcHRpbWl6YXRpb24vOTg2OTQKCSogZ2NjLnRhcmdldC9pMzg2L3ByOTg2 OTQuYzogTmV3IHRlc3QuCi0tLQogZ2NjL3JlZ2Nwcm9wLmMgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgMzMgKysrKysrKysrKysrKysrKysrKysrCiBnY2MvdGVzdHN1aXRlL2djYy50YXJnZXQv aTM4Ni9wcjk4Njk0LmMgfCAzOCArKysrKysrKysrKysrKysrKysrKysrKysrCiAyIGZpbGVzIGNo YW5nZWQsIDcxIGluc2VydGlvbnMoKykKIGNyZWF0ZSBtb2RlIDEwMDY0NCBnY2MvdGVzdHN1aXRl L2djYy50YXJnZXQvaTM4Ni9wcjk4Njk0LmMKCmRpZmYgLS1naXQgYS9nY2MvcmVnY3Byb3AuYyBi L2djYy9yZWdjcHJvcC5jCmluZGV4IGRkNjJjYjM2MDEzLi45MDgyOThiZWFlYSAxMDA2NDQKLS0t IGEvZ2NjL3JlZ2Nwcm9wLmMKKysrIGIvZ2NjL3JlZ2Nwcm9wLmMKQEAgLTM1OCw2ICszNTgsMzkg QEAgY29weV92YWx1ZSAocnR4IGRlc3QsIHJ0eCBzcmMsIHN0cnVjdCB2YWx1ZV9kYXRhICp2ZCkK ICAgZWxzZSBpZiAoc24gPiBoYXJkX3JlZ25vX25yZWdzIChzciwgdmQtPmVbc3JdLm1vZGUpKQog ICAgIHJldHVybjsKIAorICAvKiBJZiBTUkMgaGFkIGJlZW4gYXNzaWduZWQgYSBtb2RlIG5hcnJv d2VyIHRoYW4gdGhlIGNvcHksIEFsdGhvdWdoCisgICAgIHRoZXkgaGF2ZSBzYW1lIGhhcmRfcmVn bm9fbnJlZ3MsIGl0J3Mgbm90IHNhZmUgdG8gbGluayBERVNUIGludG8gdGhlCisgICAgIGNoYWlu LiAuaS5lLgorICAgICAoc2V0IChyZWc6REkgcjEpIChyZWc6REkgcjApKQorICAgICAoc2V0IChy ZWc6SEkgcjIpIChyZWc6SEkgcjEpKQorICAgICAoc2V0IChyZWc6U0kgcjMpIChyZWc6U0kgcjIp KSAvL1Nob3VsZCBiZSBhIG5ldyBjaGFpbiBzdGFydCBhdCByMworICAgICAoc2V0IChyZWc6U0kg cjQpIChyZWc6U0kgcjEpKQorICAgICAoc2V0IChyZWc6U0kgcjUpIChyZWc6U0kgcjQpKQorICAg ICB0aGUgdXBwZXIgcGFydCBvZiByMyBpcyB1bmRlZmluZWQsIGlmIGFkZGluZyBpdCB0byB0aGUg Y2hhaW4sIGl0IG1heSBiZQorICAgICBwcm9wIHRvIHI1IHdoaWNoIGhhcyBkZWZpbmVkIHVwcGVy IGJpdHMsIC5pLmUuIHByOTg2OTQuCisKKyAgICAgW0FdIHBhcnRpYWxfc3VicmVnX3AgKHZkLT5l W3NyXS5tb2RlLCBHRVRfTU9ERSAoc3JjKSkKKyAgICAgW0JdIHBhcnRpYWxfc3VicmVnX3AgKHZk LT5lW3NyXS5tb2RlLCB2ZC0+ZVt2ZC0+ZVtzcl0ub2xkZXN0X3JlZ25vXS5tb2RlKQorICAgICBD b25kaXRpb24gQiBpcyBhZGRlZCB0byB0byBjYXRjaCBvcHRpbWl6YXRpb24gb3Bwb3J0dW5pdGll cyBvZgorCisgICAgIChzZXQgKHJlZzpISSBSMSkgKHJlZzpISSBSMCkpCisgICAgIChzZXQgKHJl ZzpTSSBSMikgKHJlZzpTSSBSMSkpIC8vIFtBXQorICAgICAoc2V0IChyZWc6REkgUjMpIChyZWc6 REkgUjIpKSAvLyBbQV0KKyAgICAgKHNldCAocmVnOlNJIFI0KSAocmVnOlNJIFJbMC0zXSkpCisg ICAgIChzZXQgKHJlZzpISSBSNSkgKHJlZzpISSBSWzAtNF0pKQorCisgICAgIGJ1dCBwcm9ibGVt YXRpYyBmb3IKKworICAgICAoc2V0IChyZWc6U0kgUjEpIChyZWc6U0kgUjApKQorICAgICAoc2V0 IChyZWc6SEkgUjIpIChyZWc6SEkgUjEpKQorICAgICAoc2V0IChyZWc6U0kgUjMpIChyZWc6U0kg UjIpKSAvLyBbQV0gJiYgW0JdCisKKyAgICAgdG8gYmUgZml4ZWQ/Pz8/ICAgKi8KKyAgZWxzZSBp ZiAocGFydGlhbF9zdWJyZWdfcCAodmQtPmVbc3JdLm1vZGUsIEdFVF9NT0RFIChzcmMpKQorCSAg ICYmIHBhcnRpYWxfc3VicmVnX3AgKHZkLT5lW3NyXS5tb2RlLAorCQkJCXZkLT5lW3ZkLT5lW3Ny XS5vbGRlc3RfcmVnbm9dLm1vZGUpKQorICAgIHJldHVybjsKKwogICAvKiBMaW5rIERSIGF0IHRo ZSBlbmQgb2YgdGhlIHZhbHVlIGNoYWluIHVzZWQgYnkgU1IuICAqLwogCiAgIHZkLT5lW2RyXS5v bGRlc3RfcmVnbm8gPSB2ZC0+ZVtzcl0ub2xkZXN0X3JlZ25vOwpkaWZmIC0tZ2l0IGEvZ2NjL3Rl c3RzdWl0ZS9nY2MudGFyZ2V0L2kzODYvcHI5ODY5NC5jIGIvZ2NjL3Rlc3RzdWl0ZS9nY2MudGFy Z2V0L2kzODYvcHI5ODY5NC5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAwMDAw Li42MTFmOWU3NzYyNwotLS0gL2Rldi9udWxsCisrKyBiL2djYy90ZXN0c3VpdGUvZ2NjLnRhcmdl dC9pMzg2L3ByOTg2OTQuYwpAQCAtMCwwICsxLDM4IEBACisvKiBQUiBydGwtb3B0aW1pemF0aW9u Lzk4Njk0ICovCisvKiB7IGRnLWRvIHJ1biB7IHRhcmdldCB7ICEgaWEzMiB9IH0gfSAqLworLyog eyBkZy1vcHRpb25zICItTzIgLW1hdng1MTJidyIgfSAqLworLyogeyBkZy1yZXF1aXJlLWVmZmVj dGl2ZS10YXJnZXQgYXZ4NTEyYncgfSAqLworCisjaW5jbHVkZTxpbW1pbnRyaW4uaD4KK3R5cGVk ZWYgc2hvcnQgdjRoaSBfX2F0dHJpYnV0ZV9fICgodmVjdG9yX3NpemUgKDgpKSk7Cit0eXBlZGVm IGludCB2MnNpIF9fYXR0cmlidXRlX18gKCh2ZWN0b3Jfc2l6ZSAoOCkpKTsKK3Y0aGkgYjsKKwor X19hdHRyaWJ1dGVfXyAoKG5vaXBhKSkKK3Yyc2kKK2ZvbyAoX19tNTEyaSBzcmMxLCBfX201MTJp IHNyYzIpCit7CisgIF9fbW1hc2s2NCBtID0gX21tNTEyX2NtcGVxX2VwdThfbWFzayAoc3JjMSwg c3JjMik7CisgIHNob3J0IHMgPSAoc2hvcnQpIG07CisgIGludCBpID0gKGludCltOworICBiID0g X19leHRlbnNpb25fXyAodjRoaSkge3MsIHMsIHMsIHN9OworICByZXR1cm4gX19leHRlbnNpb25f XyAodjJzaSkge2ksIGl9OworfQorCitpbnQgbWFpbiAoKQoreworICBfX201MTJpIHNyYzEgPSBf bW01MTJfc2V0emVyb19zaTUxMiAoKTsKKyAgX19tNTEyaSBzcmMyID0gX21tNTEyX3NldF9lcGk4 ICgwLCAxLCAwLCAxLCAwLCAxLCAwLCAxLAorCQkJCSAgMCwgMSwgMCwgMSwgMCwgMSwgMCwgMSwK KwkJCQkgIDAsIDEsIDAsIDEsIDAsIDEsIDAsIDEsCisJCQkJICAwLCAxLCAwLCAxLCAwLCAxLCAw LCAxLAorCQkJCSAgMCwgMSwgMCwgMSwgMCwgMSwgMCwgMSwKKwkJCQkgIDAsIDEsIDAsIDEsIDAs IDEsIDAsIDEsCisJCQkJICAwLCAxLCAwLCAxLCAwLCAxLCAwLCAxLAorCQkJCSAgMCwgMSwgMCwg MSwgMCwgMSwgMCwgMSk7CisgIF9fbW1hc2s2NCBtID0gX21tNTEyX2NtcGVxX2VwdThfbWFzayAo c3JjMSwgc3JjMik7CisgIHYyc2kgYSA9IGZvbyAoc3JjMSwgc3JjMik7CisgIGlmIChhWzBdICE9 IChpbnQpbSkKKyAgICBfX2J1aWx0aW5fYWJvcnQgKCk7CisgIHJldHVybiAwOworfQotLSAKMi4x OC4xCgo= --000000000000ee185405b94d70d4--