This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/65368] [4.8/4.9/5 Regression]_bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate
- From: "ubizjak at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 10 Mar 2015 09:24:00 +0000
- Subject: [Bug target/65368] [4.8/4.9/5 Regression]_bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate
- Auto-submitted: auto-generated
- References: <bug-65368-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65368
--- Comment #4 from UroÅ Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #1)
> Created attachment 35000 [details]
> gcc5-pr65368.patch
>
> The problem is that the RTL pattern for bzhi doesn't really match what the
> instruction does.
> Attached is an attempt to model what the instruction does and still let
> combine put memory operands into the insn.
+ (zero_extract:SWI48
+ (match_operand:SWI48 1 "nonimmediate_operand")
+ (umin:SWI48
+ (and:SWI48 (match_operand:SWI48 2 "register_operand")
+ (const_int 255))
+ (match_dup 3))
+ (const_int 0)))
Do we really need to complicate the insn this far? I'd say that:
(zero_extract:SWI48
(match_operand:SWI48 1 "nonimmediate_operand")
(match_operand:SWI48 2 "register_operand")
(const_int 0))
should do the trick. x86 is !SHIFT_COUNT_TRUNCATED target, so combine should
not be too creative here.
(I don't have haswell to play with, so the above is just "thinking loud"...).