This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Vectorizing abs(char/short/int) on x86.
- From: Uros Bizjak <ubizjak at gmail dot com>
- To: Cong Hou <congh at google dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Richard Biener <rguenther at suse dot de>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Tue, 29 Oct 2013 18:34:57 +0100
- Subject: Re: [PATCH] Vectorizing abs(char/short/int) on x86.
- Authentication-results: sourceware.org; auth=none
- References: <CAFULd4Z0XuPm9Js00xp-9p2+0RFZDrs0hEmJNckDvOgOQrrtGA at mail dot gmail dot com> <CAK=A3=3x_BOkyUvRuimD-3r1cpbG82x+NP15OptR-BetBB_mjg at mail dot gmail dot com>
On Tue, Oct 29, 2013 at 6:18 PM, Cong Hou <email@example.com> wrote:
>>> For the define_expand I added as below, the else body is there to
>>> avoid fall-through transformations to ABS operation in optabs.c.
>>> Otherwise ABS will be converted to other operations even that we have
>>> corresponding instructions from SSSE3.
>> No, it wont be.
>> Fallthrough will generate the pattern that will be matched by the insn
>> pattern above, just like you are doing by hand below.
> I think the case is special for abs(). In optabs.c, there is a
> function expand_abs() in which the function expand_abs_nojump() is
> called. This function first tries the expand function defined for the
> target and if it fails it will try max(v, -v) then shift-xor-sub
> method. If I don't generate any instruction for SSSE3, the
> fall-through will be max(v, -v). I have tested it on my machine.
Then you can rename previous pattern to abs<mode>2_1 and call it from
the new expander instead of expanding it manually. Please also add a
small comment, describing the situation to prevent future
"optimizations" in this place.