From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id 34ED83858D32 for ; Thu, 6 Apr 2023 10:27:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 34ED83858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-wr1-x429.google.com with SMTP id e18so38992357wra.9 for ; Thu, 06 Apr 2023 03:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1680776852; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=jld0hwCsR6FhFJpDnJfWjFPQo0tTlG6yDShyjFFHLGI=; b=MIOM6E+WBEYiBm0jUsu3A6/CO2+aQl2237eQov5kuCEZkkfgJEGiiqq1HAZ4GyE6ab 9RClV/gDrgMiQJfrs/fYrLGIwqtGUjr+Sb5Zc030PT1stBJp06aGwKoTMRRrLIAYYU05 7yzdnaiepXz7lChEDzgSA8jjfGcHFyCkTFJlqCgZpst9sCzGHZH6P3rLJyXIFp7SjEsO Cf6ilY3JNiL6bc/eQPa9NmAFxdNDePjbrx83sUBwdpQSRras+yUnH6/qf+RpA8YGEQmm 59WzJSmJAZtg45V9uHKZT1x9RT1ObdvH91eqJ2LH3pPDRgbNbMj+DyWfnUjkPu8JnsdD 5MkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680776852; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jld0hwCsR6FhFJpDnJfWjFPQo0tTlG6yDShyjFFHLGI=; b=b63bMWToJbov6/kQjnm49djPM4YoOq63gMrMSlvK02BLd+sT6M4wIYkUsWO5TF7Eg3 AIqAiTd94ocyZjxCyw9rg+UsLeBINHtJAWjwGzQz749IR+QYWsUvrBBxSKyvbUQAO+u3 KqPZ4S8veXX9tYvcYUMt0U/IXOocODHK6ZS6vkHSCQrPN0TzDMZfTGPFnS52o7Ll5vsf otaSKpGritdqp3wj7NiYmSXAuIDWz2gXhpZmvbohA2TB3yMBcwx7LX3uU3ZHAfgHW+wF cAZwd/WGHa7Qq1OhJ6Ju3zzWAEvAsXzwBdE0dVSXSeWOiRKmOleJrLiqF5KpvAYhYRbM w+7g== X-Gm-Message-State: AAQBX9fpUysZTpk+sAxtLy0SU6YSKPaX5BuYuh2A6MCb2MvpKLuhPVd3 n1ICKZ4m/g+y4vag+OekpdTTJdtCs6XXUPU/kmDzrA== X-Google-Smtp-Source: AKy350bQ7g4NhgQNvNZqSkdMiGLwTAfrlZsaaMAeHOADBAHJ44ZP0Aje4n15Jmtl0BZAQOcVYJzB4SQhVscvzyU/WNI= X-Received: by 2002:a5d:5144:0:b0:2e6:d4ac:31b1 with SMTP id u4-20020a5d5144000000b002e6d4ac31b1mr1372724wrt.2.1680776851827; Thu, 06 Apr 2023 03:27:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Prathamesh Kulkarni Date: Thu, 6 Apr 2023 15:56:55 +0530 Message-ID: Subject: Re: [aarch64] Use dup and zip1 for interleaving elements in initializing vector To: Prathamesh Kulkarni , Richard Biener , gcc Patches , richard.sandiford@arm.com Content-Type: multipart/mixed; boundary="000000000000336e6505f8a85b60" X-Spam-Status: No, score=-9.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000336e6505f8a85b60 Content-Type: text/plain; charset="UTF-8" On Tue, 4 Apr 2023 at 23:35, Richard Sandiford wrote: > > Prathamesh Kulkarni writes: > > On Mon, 13 Mar 2023 at 13:03, Richard Biener wrote: > >> On GIMPLE it would be > >> > >> _1 = { a, ... }; // (a) > >> _2 = { _1, ... }; // (b) > >> > >> but I'm not sure if (b), a VL CTOR of fixed len(?) sub-vectors is > >> possible? But at least a CTOR of vectors is what we use to > >> concat vectors. > >> > >> With the recent relaxing of VEC_PERM inputs it's also possible to > >> express (b) with a VEC_PERM: > >> > >> _2 = VEC_PERM <_1, _1, { 0, 1, 2, 3, 0, 1, 2, 3, ... }> > >> > >> but again I'm not sure if that repeating 0, 1, 2, 3 is expressible > >> for VL vectors (maybe we'd allow "wrapping" here, I'm not sure). > >> > > Hi, > > Thanks for the suggestions and sorry for late response in turn. > > The attached patch tries to fix the issue by explicitly constructing a CTOR > > from svdupq's arguments and then using VEC_PERM_EXPR with VL mask > > having encoded elements {0, 1, ... nargs-1}, > > npatterns == nargs, and nelts_per_pattern == 1, to replicate the base vector. > > > > So for example, for the above case, > > svint32_t f_32(int32x4_t x) > > { > > return svdupq_s32 (x[0], x[1], x[2], x[3]); > > } > > > > forwprop1 lowers it to: > > svint32_t _6; > > vector(4) int _8; > > : > > _1 = BIT_FIELD_REF ; > > _2 = BIT_FIELD_REF ; > > _3 = BIT_FIELD_REF ; > > _4 = BIT_FIELD_REF ; > > _8 = {_1, _2, _3, _4}; > > _6 = VEC_PERM_EXPR <_8, _8, { 0, 1, 2, 3, ... }>; > > return _6; > > > > which is then eventually optimized to: > > svint32_t _6; > > [local count: 1073741824]: > > _6 = VEC_PERM_EXPR ; > > return _6; > > > > code-gen: > > f_32: > > dup z0.q, z0.q[0] > > ret > > Nice! > > > Does it look OK ? > > > > Thanks, > > Prathamesh > >> Richard. > >> > >> > We're planning to implement the ACLE's Neon-SVE bridge: > >> > https://github.com/ARM-software/acle/blob/main/main/acle.md#neon-sve-bridge > >> > and so we'll need (b) to implement the svdup_neonq functions. > >> > > >> > Thanks, > >> > Richard > >> > > >> > >> -- > >> Richard Biener > >> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, > >> Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; > >> HRB 36809 (AG Nuernberg) > > > > [SVE] Fold svld1rq to VEC_PERM_EXPR if elements are not constant. > > > > gcc/ChangeLog: > > * config/aarch64/aarch64-sve-builtins-base.cc > > (svdupq_impl::fold_nonconst_dupq): New method. > > (svdupq_impl::fold): Call fold_nonconst_dupq. > > > > gcc/testsuite/ChangeLog: > > * gcc.target/aarch64/sve/acle/general/dupq_11.c: New test. > > > > diff --git a/gcc/config/aarch64/aarch64-sve-builtins-base.cc b/gcc/config/aarch64/aarch64-sve-builtins-base.cc > > index cd9cace3c9b..3de79060619 100644 > > --- a/gcc/config/aarch64/aarch64-sve-builtins-base.cc > > +++ b/gcc/config/aarch64/aarch64-sve-builtins-base.cc > > @@ -817,6 +817,62 @@ public: > > > > class svdupq_impl : public quiet > > { > > +private: > > + gimple * > > + fold_nonconst_dupq (gimple_folder &f, unsigned factor) const > > + { > > + /* Lower lhs = svdupq (arg0, arg1, ..., argN} into: > > + tmp = {arg0, arg1, ..., arg} > > + lhs = VEC_PERM_EXPR (tmp, tmp, {0, 1, 2, N-1, ...}) */ > > + > > + /* TODO: Revisit to handle factor by padding zeros. */ > > + if (factor > 1) > > + return NULL; > > Isn't the key thing here predicate vs. vector rather than factor == 1 vs. > factor != 1? Do we generate good code for b8, where factor should be 1? Hi, It generates the following code for svdup_n_b8: https://pastebin.com/ypYt590c I suppose lowering to ctor+vec_perm_expr is not really useful for this case because it won't simplify ctor, unlike the above case of svdupq_s32 (x[0], x[1], x[2], x[3]); However I wonder if it's still a good idea to lower svdupq for predicates, for representing svdupq (or other intrinsics) using GIMPLE constructs as far as possible ? In the attached patch, it simply punts if the type suffix is b, and doesn't try to fold the call. > > > + > > + if (BYTES_BIG_ENDIAN) > > + return NULL; > > + > > + tree lhs = gimple_call_lhs (f.call); > > + if (TREE_CODE (lhs) != SSA_NAME) > > + return NULL; > > Why is this check needed? This was a left-over from something else I was doing wrongly. Sorry I forgot to remove it. > > > + tree lhs_type = TREE_TYPE (lhs); > > + tree elt_type = TREE_TYPE (lhs_type); > > + scalar_mode elt_mode = GET_MODE_INNER (TYPE_MODE (elt_type)); > > Aren't we already dealing with a scalar type here? I'd have expected > SCALAR_TYPE_MODE rather than GET_MODE_INNER (TYPE_MODE ...). Ugh, sorry, I had most of the code copied over from svld1rq_impl for building VEC_PERM_EXPR with VLA mask and adjusted it, but overlooked this :/ > > > + machine_mode vq_mode = aarch64_vq_mode (elt_mode).require (); > > + tree vq_type = build_vector_type_for_mode (elt_type, vq_mode); > > + > > + unsigned nargs = gimple_call_num_args (f.call); > > + vec *v; > > + vec_alloc (v, nargs); > > + for (unsigned i = 0; i < nargs; i++) > > + CONSTRUCTOR_APPEND_ELT (v, NULL_TREE, gimple_call_arg (f.call, i)); > > + tree vec = build_constructor (vq_type, v); > > + > > + tree access_type > > + = build_aligned_type (vq_type, TYPE_ALIGN (elt_type)); > > Nit: seems to fit on one line. But do we need this? We're not accessing > memory, so I'd have expected vq_type to be OK as-is. > > > + tree tmp = make_ssa_name_fn (cfun, access_type, 0); > > + gimple *g = gimple_build_assign (tmp, vec); > > + > > + gimple_seq stmts = NULL; > > + gimple_seq_add_stmt_without_update (&stmts, g); > > + > > + int source_nelts = TYPE_VECTOR_SUBPARTS (access_type).to_constant (); > > Looks like we should be able to use nargs instead of source_nelts. Does the attached patch look OK ? Thanks, Prathamesh > > Thanks, > Richard > > > + poly_uint64 lhs_len = TYPE_VECTOR_SUBPARTS (lhs_type); > > + vec_perm_builder sel (lhs_len, source_nelts, 1); > > + for (int i = 0; i < source_nelts; i++) > > + sel.quick_push (i); > > + > > + vec_perm_indices indices (sel, 1, source_nelts); > > + tree mask_type = build_vector_type (ssizetype, lhs_len); > > + tree mask = vec_perm_indices_to_tree (mask_type, indices); > > + > > + gimple *g2 = gimple_build_assign (lhs, VEC_PERM_EXPR, tmp, tmp, mask); > > + gimple_seq_add_stmt_without_update (&stmts, g2); > > + gsi_replace_with_seq (f.gsi, stmts, false); > > + return g2; > > + } > > + > > public: > > gimple * > > fold (gimple_folder &f) const override > > @@ -832,7 +888,7 @@ public: > > { > > tree elt = gimple_call_arg (f.call, i); > > if (!CONSTANT_CLASS_P (elt)) > > - return NULL; > > + return fold_nonconst_dupq (f, factor); > > builder.quick_push (elt); > > for (unsigned int j = 1; j < factor; ++j) > > builder.quick_push (build_zero_cst (TREE_TYPE (vec_type))); > > diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/general/dupq_11.c b/gcc/testsuite/gcc.target/aarch64/sve/acle/general/dupq_11.c > > new file mode 100644 > > index 00000000000..f19f8deb1e5 > > --- /dev/null > > +++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general/dupq_11.c > > @@ -0,0 +1,31 @@ > > +/* { dg-do compile } */ > > +/* { dg-options "-O3 -fdump-tree-optimized" } */ > > + > > +#include > > +#include > > + > > +svint8_t f_s8(int8x16_t x) > > +{ > > + return svdupq_s8 (x[0], x[1], x[2], x[3], x[4], x[5], x[6], x[7], > > + x[8], x[9], x[10], x[11], x[12], x[13], x[14], x[15]); > > +} > > + > > +svint16_t f_s16(int16x8_t x) > > +{ > > + return svdupq_s16 (x[0], x[1], x[2], x[3], x[4], x[5], x[6], x[7]); > > +} > > + > > +svint32_t f_s32(int32x4_t x) > > +{ > > + return svdupq_s32 (x[0], x[1], x[2], x[3]); > > +} > > + > > +svint64_t f_s64(int64x2_t x) > > +{ > > + return svdupq_s64 (x[0], x[1]); > > +} > > + > > +/* { dg-final { scan-tree-dump "VEC_PERM_EXPR" "optimized" } } */ > > +/* { dg-final { scan-tree-dump-not "svdupq" "optimized" } } */ > > + > > +/* { dg-final { scan-assembler-times {\tdup\tz[0-9]+\.q, z[0-9]+\.q\[0\]\n} 4 } } */ --000000000000336e6505f8a85b60 Content-Type: text/plain; charset="US-ASCII"; name="gnu-829-2.txt" Content-Disposition: attachment; filename="gnu-829-2.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lg3vnt3o0 W1NWRV0gRm9sZCBzdmxkMXJxIHRvIFZFQ19QRVJNX0VYUFIgaWYgZWxlbWVudHMgYXJlIG5vdCBj b25zdGFudC4KCmdjYy9DaGFuZ2VMb2c6CgkqIGNvbmZpZy9hYXJjaDY0L2FhcmNoNjQtc3ZlLWJ1 aWx0aW5zLWJhc2UuY2MKCShzdmR1cHFfaW1wbDo6Zm9sZF9ub25jb25zdF9kdXBxKTogTmV3IG1l dGhvZC4KCShzdmR1cHFfaW1wbDo6Zm9sZCk6IENhbGwgZm9sZF9ub25jb25zdF9kdXBxLgoKZ2Nj L3Rlc3RzdWl0ZS9DaGFuZ2VMb2c6CgkqIGdjYy50YXJnZXQvYWFyY2g2NC9zdmUvYWNsZS9nZW5l cmFsL2R1cHFfMTEuYzogTmV3IHRlc3QuCgpkaWZmIC0tZ2l0IGEvZ2NjL2NvbmZpZy9hYXJjaDY0 L2FhcmNoNjQtc3ZlLWJ1aWx0aW5zLWJhc2UuY2MgYi9nY2MvY29uZmlnL2FhcmNoNjQvYWFyY2g2 NC1zdmUtYnVpbHRpbnMtYmFzZS5jYwppbmRleCBjZDljYWNlM2M5Yi4uMTczMmJmOGJlNjEgMTAw NjQ0Ci0tLSBhL2djYy9jb25maWcvYWFyY2g2NC9hYXJjaDY0LXN2ZS1idWlsdGlucy1iYXNlLmNj CisrKyBiL2djYy9jb25maWcvYWFyY2g2NC9hYXJjaDY0LXN2ZS1idWlsdGlucy1iYXNlLmNjCkBA IC04MTcsNiArODE3LDUyIEBAIHB1YmxpYzoKIAogY2xhc3Mgc3ZkdXBxX2ltcGwgOiBwdWJsaWMg cXVpZXQ8ZnVuY3Rpb25fYmFzZT4KIHsKK3ByaXZhdGU6CisgIGdpbXBsZSAqCisgIGZvbGRfbm9u Y29uc3RfZHVwcSAoZ2ltcGxlX2ZvbGRlciAmZikgY29uc3QKKyAgeworICAgIC8qIExvd2VyIGxo cyA9IHN2ZHVwcSAoYXJnMCwgYXJnMSwgLi4uLCBhcmdOfSBpbnRvOgorICAgICAgIHRtcCA9IHth cmcwLCBhcmcxLCAuLi4sIGFyZzxOLTE+fQorICAgICAgIGxocyA9IFZFQ19QRVJNX0VYUFIgKHRt cCwgdG1wLCB7MCwgMSwgMiwgTi0xLCAuLi59KSAgKi8KKworICAgIGlmIChmLnR5cGVfc3VmZml4 ICgwKS5ib29sX3AKKwl8fCBCWVRFU19CSUdfRU5ESUFOKQorICAgICAgcmV0dXJuIE5VTEw7CisK KyAgICB0cmVlIGxocyA9IGdpbXBsZV9jYWxsX2xocyAoZi5jYWxsKTsKKyAgICB0cmVlIGxoc190 eXBlID0gVFJFRV9UWVBFIChsaHMpOworICAgIHRyZWUgZWx0X3R5cGUgPSBUUkVFX1RZUEUgKGxo c190eXBlKTsKKyAgICBzY2FsYXJfbW9kZSBlbHRfbW9kZSA9IFNDQUxBUl9UWVBFX01PREUgKGVs dF90eXBlKTsgCisgICAgbWFjaGluZV9tb2RlIHZxX21vZGUgPSBhYXJjaDY0X3ZxX21vZGUgKGVs dF9tb2RlKS5yZXF1aXJlICgpOworICAgIHRyZWUgdnFfdHlwZSA9IGJ1aWxkX3ZlY3Rvcl90eXBl X2Zvcl9tb2RlIChlbHRfdHlwZSwgdnFfbW9kZSk7CisKKyAgICB1bnNpZ25lZCBuYXJncyA9IGdp bXBsZV9jYWxsX251bV9hcmdzIChmLmNhbGwpOworICAgIHZlYzxjb25zdHJ1Y3Rvcl9lbHQsIHZh X2djPiAqdjsKKyAgICB2ZWNfYWxsb2MgKHYsIG5hcmdzKTsKKyAgICBmb3IgKHVuc2lnbmVkIGkg PSAwOyBpIDwgbmFyZ3M7IGkrKykKKyAgICAgIENPTlNUUlVDVE9SX0FQUEVORF9FTFQgKHYsIE5V TExfVFJFRSwgZ2ltcGxlX2NhbGxfYXJnIChmLmNhbGwsIGkpKTsKKyAgICB0cmVlIHZlYyA9IGJ1 aWxkX2NvbnN0cnVjdG9yICh2cV90eXBlLCB2KTsKKyAgICB0cmVlIHRtcCA9IG1ha2Vfc3NhX25h bWVfZm4gKGNmdW4sIHZxX3R5cGUsIDApOworICAgIGdpbXBsZSAqZyA9IGdpbXBsZV9idWlsZF9h c3NpZ24gKHRtcCwgdmVjKTsKKworICAgIGdpbXBsZV9zZXEgc3RtdHMgPSBOVUxMOworICAgIGdp bXBsZV9zZXFfYWRkX3N0bXRfd2l0aG91dF91cGRhdGUgKCZzdG10cywgZyk7CisKKyAgICBwb2x5 X3VpbnQ2NCBsaHNfbGVuID0gVFlQRV9WRUNUT1JfU1VCUEFSVFMgKGxoc190eXBlKTsKKyAgICB2 ZWNfcGVybV9idWlsZGVyIHNlbCAobGhzX2xlbiwgbmFyZ3MsIDEpOworICAgIGZvciAodW5zaWdu ZWQgaSA9IDA7IGkgPCBuYXJnczsgaSsrKQorICAgICAgc2VsLnF1aWNrX3B1c2ggKGkpOworCisg ICAgdmVjX3Blcm1faW5kaWNlcyBpbmRpY2VzIChzZWwsIDEsIG5hcmdzKTsKKyAgICB0cmVlIG1h c2tfdHlwZSA9IGJ1aWxkX3ZlY3Rvcl90eXBlIChzc2l6ZXR5cGUsIGxoc19sZW4pOworICAgIHRy ZWUgbWFzayA9IHZlY19wZXJtX2luZGljZXNfdG9fdHJlZSAobWFza190eXBlLCBpbmRpY2VzKTsK KworICAgIGdpbXBsZSAqZzIgPSBnaW1wbGVfYnVpbGRfYXNzaWduIChsaHMsIFZFQ19QRVJNX0VY UFIsIHRtcCwgdG1wLCBtYXNrKTsKKyAgICBnaW1wbGVfc2VxX2FkZF9zdG10X3dpdGhvdXRfdXBk YXRlICgmc3RtdHMsIGcyKTsKKyAgICBnc2lfcmVwbGFjZV93aXRoX3NlcSAoZi5nc2ksIHN0bXRz LCBmYWxzZSk7CisgICAgcmV0dXJuIGcyOworICB9CisKIHB1YmxpYzoKICAgZ2ltcGxlICoKICAg Zm9sZCAoZ2ltcGxlX2ZvbGRlciAmZikgY29uc3Qgb3ZlcnJpZGUKQEAgLTgzMiw3ICs4NzgsNyBA QCBwdWJsaWM6CiAgICAgICB7CiAJdHJlZSBlbHQgPSBnaW1wbGVfY2FsbF9hcmcgKGYuY2FsbCwg aSk7CiAJaWYgKCFDT05TVEFOVF9DTEFTU19QIChlbHQpKQotCSAgcmV0dXJuIE5VTEw7CisJICBy ZXR1cm4gZm9sZF9ub25jb25zdF9kdXBxIChmKTsKIAlidWlsZGVyLnF1aWNrX3B1c2ggKGVsdCk7 CiAJZm9yICh1bnNpZ25lZCBpbnQgaiA9IDE7IGogPCBmYWN0b3I7ICsraikKIAkgIGJ1aWxkZXIu cXVpY2tfcHVzaCAoYnVpbGRfemVyb19jc3QgKFRSRUVfVFlQRSAodmVjX3R5cGUpKSk7CmRpZmYg LS1naXQgYS9nY2MvdGVzdHN1aXRlL2djYy50YXJnZXQvYWFyY2g2NC9zdmUvYWNsZS9nZW5lcmFs L2R1cHFfMTEuYyBiL2djYy90ZXN0c3VpdGUvZ2NjLnRhcmdldC9hYXJjaDY0L3N2ZS9hY2xlL2dl bmVyYWwvZHVwcV8xMS5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAwMDAwLi5m MTlmOGRlYjFlNQotLS0gL2Rldi9udWxsCisrKyBiL2djYy90ZXN0c3VpdGUvZ2NjLnRhcmdldC9h YXJjaDY0L3N2ZS9hY2xlL2dlbmVyYWwvZHVwcV8xMS5jCkBAIC0wLDAgKzEsMzEgQEAKKy8qIHsg ZGctZG8gY29tcGlsZSB9ICovCisvKiB7IGRnLW9wdGlvbnMgIi1PMyAtZmR1bXAtdHJlZS1vcHRp bWl6ZWQiIH0gKi8KKworI2luY2x1ZGUgPGFybV9zdmUuaD4KKyNpbmNsdWRlIDxhcm1fbmVvbi5o PgorCitzdmludDhfdCBmX3M4KGludDh4MTZfdCB4KQoreworICByZXR1cm4gc3ZkdXBxX3M4ICh4 WzBdLCB4WzFdLCB4WzJdLCB4WzNdLCB4WzRdLCB4WzVdLCB4WzZdLCB4WzddLAorCQkgICAgeFs4 XSwgeFs5XSwgeFsxMF0sIHhbMTFdLCB4WzEyXSwgeFsxM10sIHhbMTRdLCB4WzE1XSk7Cit9CisK K3N2aW50MTZfdCBmX3MxNihpbnQxNng4X3QgeCkKK3sKKyAgcmV0dXJuIHN2ZHVwcV9zMTYgKHhb MF0sIHhbMV0sIHhbMl0sIHhbM10sIHhbNF0sIHhbNV0sIHhbNl0sIHhbN10pOworfQorCitzdmlu dDMyX3QgZl9zMzIoaW50MzJ4NF90IHgpCit7CisgIHJldHVybiBzdmR1cHFfczMyICh4WzBdLCB4 WzFdLCB4WzJdLCB4WzNdKTsKK30KKworc3ZpbnQ2NF90IGZfczY0KGludDY0eDJfdCB4KQorewor ICByZXR1cm4gc3ZkdXBxX3M2NCAoeFswXSwgeFsxXSk7Cit9CisKKy8qIHsgZGctZmluYWwgeyBz Y2FuLXRyZWUtZHVtcCAiVkVDX1BFUk1fRVhQUiIgIm9wdGltaXplZCIgfSB9ICovCisvKiB7IGRn LWZpbmFsIHsgc2Nhbi10cmVlLWR1bXAtbm90ICJzdmR1cHEiICJvcHRpbWl6ZWQiIH0gfSAqLwor CisvKiB7IGRnLWZpbmFsIHsgc2Nhbi1hc3NlbWJsZXItdGltZXMge1x0ZHVwXHR6WzAtOV0rXC5x LCB6WzAtOV0rXC5xXFswXF1cbn0gNCB9IH0gKi8K --000000000000336e6505f8a85b60--