On Fri, Jun 29, 2012 at 11:00:14AM +0200, Richard Guenther wrote:
> Indeed - the lack of cross-sub-128bit-word operations makes it very much
> expensive for some vectorizations. Initially we added the patterns for
> vectorization of the hi/lo and interleave stuff because we didn't want
> regressio
On Thu, Jun 28, 2012 at 6:44 PM, H.J. Lu wrote:
> On Thu, Jun 28, 2012 at 8:57 AM, Richard Henderson wrote:
>> On 2012-06-28 07:05, Jakub Jelinek wrote:
>>> Unfortunately the addition of the builtin_mul_widen_* hooks on i?86 seems
>>> to pessimize the generated code for gcc.dg/vect/pr51581-3.c
>>
On Fri, Jun 29, 2012 at 12:00:10AM +0200, Bernhard Reutner-Fischer wrote:
> Really both HI? If so optab2 could be removed from that fn altogether..
Of course, thanks for pointing that out. I've additionally added a result
mode check (similar to what supportable_widening_operation does).
The reaso
On Thu, Jun 28, 2012 at 04:05:58PM +0200, Jakub Jelinek wrote:
>On Thu, Jun 28, 2012@09:17:55AM +0200, Jakub Jelinek wrote:
>> I'll look@using MULT_HIGHPART_EXPR in the pattern recognizer and
>> vectorizing it as either of the sequences next.
>
>And here is corresponding pattern recognizer and vect
On 2012-06-28 07:05, Jakub Jelinek wrote:
> PR tree-optimization/51581
> * tree-vect-stmts.c (permute_vec_elements): Add forward decl.
> (vectorizable_operation): Handle vectorization of MULT_HIGHPART_EXPR
> also using VEC_WIDEN_MULT_*_EXPR or builtin_mul_widen_* plus
>
On 2012-06-28 00:17, Jakub Jelinek wrote:
> 2012-06-28 Jakub Jelinek
>
> PR tree-optimization/53645
> * tree-vect-generic.c (expand_vector_divmod): Use MULT_HIGHPART_EXPR
> instead of VEC_WIDEN_MULT_{HI,LO}_EXPR followed by VEC_PERM_EXPR
> if possible.
>
> * gcc.c
On 2012-06-28 09:20, Jakub Jelinek wrote:
> Perhaps the problem is then that the permutation is much more expensive
> for even/odd. With even/odd the f2 routine is:
...
> vpshufb %xmm2, %xmm5, %xmm5
> vpshufb %xmm1, %xmm4, %xmm4
> vpor%xmm4, %xmm5, %xmm4
...
> and with
On Thu, Jun 28, 2012 at 8:57 AM, Richard Henderson wrote:
> On 2012-06-28 07:05, Jakub Jelinek wrote:
>> Unfortunately the addition of the builtin_mul_widen_* hooks on i?86 seems
>> to pessimize the generated code for gcc.dg/vect/pr51581-3.c
>> testcase (at least with -O3 -mavx) compared to when t
On Thu, Jun 28, 2012 at 08:57:23AM -0700, Richard Henderson wrote:
> On 2012-06-28 07:05, Jakub Jelinek wrote:
> > Unfortunately the addition of the builtin_mul_widen_* hooks on i?86 seems
> > to pessimize the generated code for gcc.dg/vect/pr51581-3.c
> > testcase (at least with -O3 -mavx) compare
On 2012-06-28 07:05, Jakub Jelinek wrote:
> Unfortunately the addition of the builtin_mul_widen_* hooks on i?86 seems
> to pessimize the generated code for gcc.dg/vect/pr51581-3.c
> testcase (at least with -O3 -mavx) compared to when the hooks aren't
> present, because i?86 has more natural support
On Thu, Jun 28, 2012 at 09:17:55AM +0200, Jakub Jelinek wrote:
> I'll look at using MULT_HIGHPART_EXPR in the pattern recognizer and
> vectorizing it as either of the sequences next.
And here is corresponding pattern recognizer and vectorizer patch.
Bootstrapped/regtested on x86_64-linux and i686
On Wed, Jun 27, 2012 at 02:37:08PM -0700, Richard Henderson wrote:
>
> I was sitting on this patch until I got around to fixing up Jakub's
> existing vector divmod code to use it. But seeing as how he's adding
> more uses, I think it's better to get it in earlier.
>
> Tested via a patch sent und
On 06/27/2012 02:42 PM, Steven Bosscher wrote:
> Maybe also a bit in doc/generic.texi? Or is this not supposed to be
> exposed to the front ends?
I can't imagine it being terribly useful to front ends, but there's
certainly nothing that ought to prevent it. How's this?
r~
diff --git a/gcc/doc/g
On Wed, Jun 27, 2012 at 11:37 PM, Richard Henderson wrote:
> * tree.def (MULT_HIGHPART_EXPR): New.
> * cfgexpand.c (expand_debug_expr): Ignore it.
> * expr.c (expand_expr_real_2): Handle it.
> * fold-const.c (int_const_binop_1): Likewise.
> * optabs.c (optab_for_
I was sitting on this patch until I got around to fixing up Jakub's
existing vector divmod code to use it. But seeing as how he's adding
more uses, I think it's better to get it in earlier.
Tested via a patch sent under separate cover that changes
__builtin_alpha_umulh to immediately fold to MUL
15 matches
Mail list logo
