https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124007

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |middle-end

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> aarch64 looks ok:
>         eor     x3, x4, x3
>         tbnz    x3, 21, .L22
> ...
>         tbz     x4, 21, .L23
> 
> 
> clang produces:
>         bexti   a1, a1, 21
>         bexti   a2, a2, 21
>         bne     a1, a2, .LBB0_7
>         bnez    a1, .LBB0_8
> 
> Maybe the easiest way is to implement tbranch_* patterns in the riscv
> backend.
> ```
> @cindex @code{tbranch_@var{op}@var{mode}3} instruction pattern
> @item @samp{tbranch_@var{op}@var{mode}3}
> Conditional branch instruction combined with a bit test-and-compare
> instruction. Operand 0 is the operand of the comparison.  Operand 1 is the
> bit
> position of Operand 1 to test.  Operand 3 is the @code{code_label} to jump
> to.
> @var{op} is one of @var{eq} or @var{ne}.
> ```
> which does the extraction seperately from the branch.

And then you would get:
xor     a2, a1, a2
bexti   a1, a1, 21
bexti   a2, a2, 21
bnez    a2, .LBB0_7
bnez    a1, .LBB0_8

Which might be still better than what is currently done though.

But that does get you what LLVM gives though. 
The problem is the ^ and the 2 & here. where the second extraction is unrelated
to the first one.

Reply via email to