[PATCH] D34904: [CGP] use subtract of cmps for result of memcmp expansion

Sanjay Patel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jul 11 05:50:29 PDT 2017


spatel added a comment.

In https://reviews.llvm.org/D34904#804655, @nemanjai wrote:

> We have patches that will eventually land that improve our handling of zero-extending `i1` in the PPC back end so I'm not overly concern about the slightly poorer code here. However, I'd like to make sure I understand the reason for this change.
>
> 1. On targets that will expand selects to branches, we want to avoid introducing selects to reduce branching
> 2. Recreating a select in the DAG is possible and getting rid of the select in the DAG is impossible on targets that expand it to branches
> 3. Making this choice conditional on something like an IR-level version of `canInsertSelect()` (maybe something called `shouldInsertSelect()`...) introduces unnecessary complexity
>
>   Does that evaluation roughly cover the motivation for this patch?


That's correct, although if pre-DAG select-to-branch transforms are a concern, then this is just a tiny example of that.

I admit that when I saw the branchy output on some of the x86 tests, I thought this was happening already, but it turns out those branches are created later. When I realized we could create the memcmp result with a subtract, however, I thought that would translate to better codegen for both PPC and x86 without introducing more DAG transforms.

It turns out we'll have to add those transforms anyway if the related llvm-dev thread ( http://lists.llvm.org/pipermail/llvm-dev/2017-July/114885.html ) continues in its current direction. So the practical motivation is that we're producing better code for memcmp() for x86 (and PPC if we avoid the isels?) without waiting for that extra DAG step to improve codegen.


https://reviews.llvm.org/D34904





More information about the llvm-commits mailing list