From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id DF50E3858D35 for ; Fri, 7 Aug 2020 06:38:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DF50E3858D35 Received: by mail-ej1-x635.google.com with SMTP id o23so944362ejr.1 for ; Thu, 06 Aug 2020 23:38:57 -0700 (PDT) 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:cc; bh=/UY7UX3MVElJE6KgxHVy/9gBlv/iXmdij65MDB+fBF4=; b=aXg/l6dE4frYzQ/GIFp8WnmWnJ81BLqLhBxHLHiih1RF/B4I68Mox66n7gUIxMmmgx C/TGdIY/ofjdBUI6cpEzfkbtLzWR2lOUijRQcwmUJa9pUa8qLDA+FiMFqwQ7UoTvV8Hv AX37sVblvE+N4bHA6WmCnFeHcfpH34iwUWW6lAFL/ZSKBfl4CHUfUTGOVaBzY5AGBRN5 5VWXZFQaIGOoQ3vUIB/z/TTYssQRy7UVdTeKWDrFwegbX35+xlQuNYhRHBttTGKpnvX0 9nDxxIAtZQXnaUpwWtZjrW+hFQ3RI5ipf77vTpD6cVVYlEeKRH52mHGfV7VoBNTvZ3p6 Q3DQ== X-Gm-Message-State: AOAM5319hWtk7fboCgdbebg6JMmR78vu4AyALad4Eryig5YiySPJuSd0 qPWcqbaxBiPJD0U9jrEtNTl+izKSwqErGmJ6/6U= X-Google-Smtp-Source: ABdhPJxBqmJDCYTQcL6+TGfCO2Q18pzeIa4Gl6r2oJnfpgbv4dp5r6jQmEQE9aV0DeojytskZEekO7fgb6f7Yb2uNc8= X-Received: by 2002:a17:906:f914:: with SMTP id lc20mr7815484ejb.138.1596782336842; Thu, 06 Aug 2020 23:38:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Fri, 7 Aug 2020 08:38:45 +0200 Message-ID: Subject: Re: VEC_COND_EXPR optimizations v2 To: Marc Glisse Cc: Christophe Lyon , GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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: Fri, 07 Aug 2020 06:38:59 -0000 On Thu, Aug 6, 2020 at 8:07 PM Marc Glisse wrote: > > On Thu, 6 Aug 2020, Christophe Lyon wrote: > > >> Was I on the right track configuring with > >> --target=arm-none-linux-gnueabihf --with-cpu=cortex-a9 > >> --with-fpu=neon-fp16 > >> then compiling without any special option? > > > > Maybe you also need --with-float=hard, I don't remember if it's > > implied by the 'hf' target suffix > > Thanks! That's what I was missing to reproduce the issue. Now I can > reproduce it with just > > typedef unsigned int vec __attribute__((vector_size(16))); > typedef int vi __attribute__((vector_size(16))); > vi f(vec a,vec b){ > return a==5 | b==7; > } > > with -fdisable-tree-forwprop1 -fdisable-tree-forwprop2 -fdisable-tree-forwprop3 -O1 > > _1 = a_5(D) == { 5, 5, 5, 5 }; > _3 = b_6(D) == { 7, 7, 7, 7 }; > _9 = _1 | _3; > _7 = .VCOND (_9, { 0, 0, 0, 0 }, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }, 107); > > we fail to expand the equality comparison (expand_vec_cmp_expr_p returns > false), while with -fdisable-tree-forwprop4 we do manage to expand > > _2 = .VCONDU (a_5(D), { 5, 5, 5, 5 }, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }, 112); > > It doesn't make much sense to me that we can expand the more complicated > form and not the simpler form of the same operation (both compare a to 5 > and produce a vector of -1 or 0 of the same size), especially when the > target has an instruction (vceq) that does just what we want. > > Introducing boolean vectors was fine, but I think they should be real > types, that we can operate on, not be forced to appear only as the first > argument of a vcond. > > I can think of 2 natural ways to improve things: either implement vector > comparisons in the ARM backend (possibly by forwarding to their existing > code for vcond), or in the generic expansion code try using vcond if the > direct comparison opcode is not provided. > > We can temporarily revert my patch, but I would like it to be temporary. > Since aarch64 seems to handle the same code just fine, maybe someone who > knows arm could copy the relevant code over? > > Does my message make sense, do people have comments? So what complicates things now (and to some extent pre-existed when you used AVX512 which _could_ operate on boolean vectors) is that we have split out the condition from VEC_COND_EXPR to separate stmts but we do not expect backends to be able to code-generate the separate form - instead we rely on the ISEL pass to trasform VEC_COND_EXPRs to .VCOND[U] "merging" the compares again. Now that process breaks down once we have things like _9 = _1 | _3; - at some point I argued that we should handle vector compares [and operations on boolean vectors] as well in ISEL but then when it came up again for some reason I disregarded that again. Thus - we don't want to go back to fixing up the generic expansion code (which looks at one instruction at a time and is restricted by TER single-use restrictions). Instead we want to deal with this in ISEL which should behave more intelligently. In the above case it might involve turning the _1 and _3 defs into .VCOND [with different result type], doing _9 in that type and then somehow dealing with _7 ... but this eventually means undoing the match simplification that introduced the code? Not sure if that helps though. Richard. > -- > Marc Glisse