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.