More vector folding

2013-06-13 Thread Marc Glisse
noticed the following: double f(double x){ return -2*x; } double g(double x){ return 2*-x; } generates mulsd for f and xorpd+addsd for g, I should probably file a PR about that, the running time may be similar but it is better to canonicalize. 2013-06-14 Marc Glisse marc.gli...@inria.fr

Re: Remove self-assignments

2013-06-12 Thread Marc Glisse
On Wed, 12 Jun 2013, Richard Biener wrote: On Tue, Jun 11, 2013 at 9:30 PM, Marc Glisse marc.gli...@inria.fr wrote: On Tue, 11 Jun 2013, Jeff Law wrote: On 06/09/13 10:25, Marc Glisse wrote: Hello, this patch removes some self-assignments. I don't know if this is the best way

Re: More forwprop for vectors

2013-06-12 Thread Marc Glisse
On Wed, 12 Jun 2013, Richard Biener wrote: On Tue, Jun 11, 2013 at 9:44 PM, Marc Glisse marc.gli...@inria.fr wrote: On Tue, 11 Jun 2013, Jeff Law wrote: On 06/09/13 13:43, Marc Glisse wrote: Hello, just adapting yet another function so it also works with vectors. It seemed convenient

Re: More forwprop for vectors

2013-06-12 Thread Marc Glisse
On Wed, 12 Jun 2013, Marc Glisse wrote: On Wed, 12 Jun 2013, Richard Biener wrote: I suppose it's explicitely not allowing complex integer constants? Hmm... Thanks, I keep forgetting complex :-( Do we want A+~A - -1-i for integer complex types? Is using BIT_NOT_EXPR on them even legal

Re: Remove self-assignments

2013-06-12 Thread Marc Glisse
On Wed, 12 Jun 2013, Richard Biener wrote: On Wed, Jun 12, 2013 at 10:47 AM, Marc Glisse marc.gli...@inria.fr wrote: Essentially never. I tried with the fold_stmt version of the patch, and libstdc++-v3/src/c++98/concept-inst.cc is the only file where it triggers. Note that the case: b=*a *a=b

Re: More forwprop for vectors

2013-06-12 Thread Marc Glisse
On Wed, 12 Jun 2013, Marc Glisse wrote: I suppose it's explicitely not allowing complex integer constants? Hmm... Thanks, I keep forgetting complex :-( And complex is even more of a pain than vector to handle. Testing for CONSTANT_CLASS_P seems sufficient here. Some transformations also

Re: [PATCH 0/4] Fix leading and trailing whitespaces.

2013-06-12 Thread Marc Glisse
wrote: A followup to previous patch is more general pass that changes leading spaces to tabs followed by at most 8 spaces. s/at most/less than/ -- Marc Glisse

Re: More forwprop for vectors

2013-06-12 Thread Marc Glisse
On Wed, 12 Jun 2013, Jeff Law wrote: On 06/12/13 14:17, Marc Glisse wrote: On Wed, 12 Jun 2013, Marc Glisse wrote: I suppose it's explicitely not allowing complex integer constants? Hmm... Thanks, I keep forgetting complex :-( And complex is even more of a pain than vector to handle

Re: [RFC] Implement Undefined Behavior Sanitizer (take 2)

2013-06-11 Thread Marc Glisse
= fold_build3 (COND_EXPR, void_type_node, t, tt, void_zero_node); + + return t; +} -- Marc Glisse

Re: Remove self-assignments

2013-06-11 Thread Marc Glisse
On Tue, 11 Jun 2013, Jeff Law wrote: On 06/09/13 10:25, Marc Glisse wrote: Hello, this patch removes some self-assignments. I don't know if this is the best way, but it passes a bootstrap and the testsuite on x86_64-linux-gnu. 2013-06-10 Marc Glisse marc.gli...@inria.fr PR tree

Re: More forwprop for vectors

2013-06-11 Thread Marc Glisse
On Tue, 11 Jun 2013, Jeff Law wrote: On 06/09/13 13:43, Marc Glisse wrote: Hello, just adapting yet another function so it also works with vectors. It seemed convenient to add a new macro. The name sucks (it doesn't match the semantics of INTEGRAL_TYPE_P), but I didn't want to name

[C++] Fix __builtin_shuffle

2013-06-09 Thread Marc Glisse
Hello, when porting __builtin_shuffle from C to C++, I ignored all the C++ specificities and added some extra bugs. This should improve things a bit. Bootstrap+testsuite on x86_64-linux-gnu. 2013-06-10 Marc Glisse marc.gli...@inria.fr PR c++/57509 gcc/c-family/ * c

Remove self-assignments

2013-06-09 Thread Marc Glisse
Hello, this patch removes some self-assignments. I don't know if this is the best way, but it passes a bootstrap and the testsuite on x86_64-linux-gnu. 2013-06-10 Marc Glisse marc.gli...@inria.fr PR tree-optimization/57361 gcc/ * tree-ssa-dse.c (dse_possible_dead_store_p

Document __builtin_isinf_sign more precisely

2013-06-09 Thread Marc Glisse
Hello, this patch documents that __builtin_isinf_sign returns +-1 for +-Inf. This builtin was created so it could be used by a libc that has a stronger guarantee than the standard, and for glibc that means returning +-1, which is what the code already does. 2013-06-10 Marc Glisse marc.gli

[x86] Remove 2 builtins

2013-06-09 Thread Marc Glisse
Hello, this patch removes 2 builtins that are undocumented, unused, and have confusing semantics. Bootstrap+testsuite on x86_64-linux-gnu. 2013-06-10 Marc Glisse marc.gli...@inria.fr PR target/57224 * config/i386/i386.c (enum ix86_builtins, bdesc_args): Remove

Re: [RFC] Implement Undefined Behavior Sanitizer (take 2)

2013-06-08 Thread Marc Glisse
(cop1) != INTEGER_CST + || integer_zerop (cop1) + || integer_minus_onep (cop1))) + doing_div_or_mod = true; Aren't you already doing this test in ubsan_instrument_division? -- Marc Glisse

Re: Use unsigned(-1) for lshift

2013-05-25 Thread Marc Glisse
.) -- Marc Glisse

Simplify (double)i != 0

2013-05-25 Thread Marc Glisse
on x86_64-linux-gnu. 2013-05-27 Marc Glisse marc.gli...@inria.fr PR tree-optimization/57371 gcc/ * fold-const.c (fold_comparison): Fold comparison of a FLOAT_EXPR with 0. gcc/testsuite/ * gcc.dg/pr57371-1.c: New testcase. * gcc.dg/pr57371-2.c: Likewise

Re: Use unsigned(-1) for lshift

2013-05-24 Thread Marc Glisse
On Fri, 24 May 2013, Richard Biener wrote: On Thu, May 23, 2013 at 9:47 PM, Marc Glisse marc.gli...@inria.fr wrote: Hello, this is a simple patch to reduce a bit the noise in PR57324 (undefined behavior flagged by clang). I only handled some of the most obvious ones. Passes bootstrap

Re: Use unsigned(-1) for lshift

2013-05-24 Thread Marc Glisse
On Fri, 24 May 2013, Jakub Jelinek wrote: On Fri, May 24, 2013 at 10:15:29AM +0200, Richard Biener wrote: On Thu, May 23, 2013 at 9:47 PM, Marc Glisse marc.gli...@inria.fr wrote: Hello, this is a simple patch to reduce a bit the noise in PR57324 (undefined behavior flagged by clang). I only

Use unsigned(-1) for lshift

2013-05-23 Thread Marc Glisse
Hello, this is a simple patch to reduce a bit the noise in PR57324 (undefined behavior flagged by clang). I only handled some of the most obvious ones. Passes bootstrap+testsuite on x86_64-linux-gnu. 2013-05-24 Marc Glisse marc.gli...@inria.fr PR other/57324 * expmed.c

C++ copy elision and alignment

2013-05-18 Thread Marc Glisse
Hello, this patch passes bootstrap+testsuite on x86_64-linux-gnu. As explained in the PR, it seems that the check for alignment is in the wrong direction (tree-nrv.c and ada have the reverse one). 2013-05-18 Marc Glisse marc.gli...@inria.fr PR c++/57175 gcc/cp/ * typeck.c

Re: More vector folding

2013-05-17 Thread Marc Glisse
On Fri, 17 May 2013, Hans-Peter Nilsson wrote: From: Marc Glisse marc.gli...@inria.fr Date: Tue, 14 May 2013 13:47:23 +0200 Here is what I tested during the night, I'll just rename the function. I took the chance to remove an unnecessary alternative in TRUTH_XOR_EXPR. Passes bootstrap

Re: More vector folding

2013-05-17 Thread Marc Glisse
On Fri, 17 May 2013, Jakub Jelinek wrote: On Fri, May 17, 2013 at 09:54:14PM +0800, Chung-Ju Wu wrote: 2013/5/17 Marc Glisse marc.gli...@inria.fr: Yes, LOGICAL_OP_NON_SHORT_CIRCUIT seems to be it. What is the proper thing to do here? If I add the generic xfail back, we'll get xpass on some

Re: More vector folding

2013-05-17 Thread Marc Glisse
On Fri, 17 May 2013, Jakub Jelinek wrote: On Fri, May 17, 2013 at 04:23:08PM +0200, Marc Glisse wrote: 2013-05-17 Marc Glisse marc.gli...@inria.fr PR regression/57313 * gcc.dg/binop-xor3.c: Restrict to platforms known to work (x86). I'd say it should be PR testsuite/57313

Break infinite folding loop

2013-05-16 Thread Marc Glisse
the rest later. Passes bootstrap+testsuite on x86_64-linux-gnu. 2013-05-16 Marc Glisse marc.gli...@inria.fr PR middle-end/57286 gcc/ * fold-const.c (fold_ternary_loc) VEC_COND_EXPR: Disable some transformations to avoid an infinite loop. gcc/testsuite/ * gcc.dg

Re: Break infinite folding loop

2013-05-16 Thread Marc Glisse
On Thu, 16 May 2013, Richard Biener wrote: On Thu, May 16, 2013 at 8:42 AM, Marc Glisse marc.gli...@inria.fr wrote: Hello, we can get into a cycle where: (x0)|1 becomes (x0)?-1:1 and (y?-1:1) becomes y|1 Contrary to what I posted in the PR, I am disabling the second transformation here

[C++] Don't build NE_EXPR manually

2013-05-16 Thread Marc Glisse
on x86_64-linux-gnu. 2013-05-16 Marc Glisse marc.gli...@inria.fr gcc/cp/ * call.c (build_conditional_expr_1): Use cp_build_binary_op instead of directly calling fold_build2. gcc/testsuite/ * g++.dg/ext/vector22.C: Uncomment working test. -- Marc GlisseIndex: cp/call.c

Re: GCC does not support *mmintrin.h with function specific opts

2013-05-16 Thread Marc Glisse
the change to x86intrin.h instead of making it inside each *mmintrin.h header. The code would be the same size, it would let us include smmintrin.h directly if we wanted to, and x86intrin.h would also automatically work. -- Marc Glisse

Restore m68k bootstrap

2013-05-14 Thread Marc Glisse
bootstrap on m68k. 2013-05-13 Marc Glisse marc.gli...@inria.fr PR bootstrap/57266 * fold-const.c (fold_binary_loc) shift: Use an unsigned variable for the shift amount. Check that we shift by non-negative amounts. -- Marc GlisseIndex: gcc/fold-const.c

Re: Restore m68k bootstrap

2013-05-14 Thread Marc Glisse
On Tue, 14 May 2013, Richard Biener wrote: On Tue, May 14, 2013 at 1:23 PM, Marc Glisse marc.gli...@inria.fr wrote: Hello, in an earlier patch I apparently introduced a platform dependent signed / unsigned comparison, so here is a fix. I am taking the chance to fix the host_integerp second

Re: More vector folding

2013-05-14 Thread Marc Glisse
On Tue, 14 May 2013, Richard Biener wrote: On Mon, May 13, 2013 at 1:40 PM, Marc Glisse marc.gli...@inria.fr wrote: On Mon, 13 May 2013, Richard Biener wrote: On Sat, May 11, 2013 at 11:38 AM, Marc Glisse marc.gli...@inria.fr wrote: @@ -8274,28 +8269,34 @@ fold_unary_loc (location_t loc

Re: More vector folding

2013-05-13 Thread Marc Glisse
On Mon, 13 May 2013, Richard Biener wrote: On Sat, May 11, 2013 at 11:38 AM, Marc Glisse marc.gli...@inria.fr wrote: Second try. I removed the fold_single_bit_test thing (I thought I'd handle it, so I started by the easy part, and never did the rest). Adapting invert_truthvalue_loc

Re: Prefer scalar offset in vector shifts

2013-05-13 Thread Marc Glisse
On Mon, 13 May 2013, Jakub Jelinek wrote: On Sun, May 12, 2013 at 02:04:52PM +0200, Marc Glisse wrote: this patch passes bootstrap+testsuite on x86_64-linux-gnu. When moving uniform_vector_p, I only added the gcc_assert. Note that the fold_binary patch helps for constant vectors

Prefer scalar offset in vector shifts

2013-05-12 Thread Marc Glisse
done by the vector lowering pass, but that's too late in my opinion. 2013-05-13 Marc Glisse marc.gli...@inria.fr gcc/ * tree-vect-generic.c (uniform_vector_p): Move ... * tree.c (uniform_vector_p): ... here. * tree.h (uniform_vector_p): Declare it. * fold

Re: More vector folding

2013-05-11 Thread Marc Glisse
of the front-end (affects warnings) and folding. I hesitated between removing this cast and enhancing fold_convert, and chose the one that removes code. As a side benefit, I got an XPASS :-) Passes bootstrap+testsuite on x86_64-linux-gnu. 2013-05-11 Marc Glisse marc.gli...@inria.fr gcc

Re: More vector folding

2013-05-10 Thread Marc Glisse
On Fri, 10 May 2013, Richard Biener wrote: On Thu, May 9, 2013 at 12:55 AM, Marc Glisse marc.gli...@inria.fr wrote: Hello, here are a few more changes to fold-const.c so vectors can use the existing optimizations. Note that I made fold_truth_not_expr safe for use with vector BIT_NOT_EXPR

Re: [PATCH] Rotate pattern recognition in forwprop (PR tree-optimization/57157)

2013-05-09 Thread Marc Glisse
)) OP ((T) (Z CNT2)) to: (T) Z r CNT1 and if by chance Z was (T2) X, the 2 casts would collapse in the next round. That might be a bit more generic (probably not very noticable), and the pattern a bit shorter. -- Marc Glisse

More vector folding

2013-05-08 Thread Marc Glisse
Hello, here are a few more changes to fold-const.c so vectors can use the existing optimizations. Note that I made fold_truth_not_expr safe for use with vector BIT_NOT_EXPR. Passes bootstrap+testsuite on x86_64-linux-gnu. 2013-05-09 Marc Glisse marc.gli...@inria.fr gcc/ * fold

all_ones vs minus_one (was: [PATCH] Loop distribution improvements)

2013-05-07 Thread Marc Glisse
} for instance, but I didn't add that. 2013-05-07 Marc Glisse marc.gli...@inria.fr * convert.c (convert_to_integer): Replace integer_all_onesp with integer_minus_onep. * tree-ssa-loop-niter.c (number_of_iterations_lt, number_of_iterations_exit): Likewise

Re: all_ones vs minus_one (was: [PATCH] Loop distribution improvements)

2013-05-07 Thread Marc Glisse
On Tue, 7 May 2013, Marc Glisse wrote: On Thu, 2 May 2013, Richard Biener wrote: Can you followup with a patch to do s/integer_all_onesp/integer_minus_onep/ where it makes sense? This passes bootstrap+testsuite on x86_64-linux-gnu. I kept all_ones for bitmask type of operations (BIT_*_EXPR

Re: all_ones vs minus_one (was: [PATCH] Loop distribution improvements)

2013-05-07 Thread Marc Glisse
On Tue, 7 May 2013, Richard Biener wrote: On Tue, 7 May 2013, Marc Glisse wrote: On Thu, 2 May 2013, Richard Biener wrote: Can you followup with a patch to do s/integer_all_onesp/integer_minus_onep/ where it makes sense? This passes bootstrap+testsuite on x86_64-linux-gnu. I kept all_ones

TYPE_PRECISION for vectors

2013-05-07 Thread Marc Glisse
for complex and vector seems questionable: I think that it is the same as for the inner type, which is already hashed. I didn't change that in the patch. Passes bootstrap+testsuite on x86_64-linux-gnu. 2013-05-07 Marc Glisse marc.gli...@inria.fr gcc/ * stor-layout.c (element_precision

Re: TYPE_PRECISION for vectors

2013-05-07 Thread Marc Glisse
On Tue, 7 May 2013, Marc Glisse wrote: * fold-const.c (operand_equal_p): Use element_precision. (fold_binary_loc): Handle vector types. Note that this causes a regression in some cases: it now recognizes LROTATE_EXPR for vectors, but then on x86_64 it isn't a supported vector

[C++] Missing save_expr in vector-scalar ops

2013-05-06 Thread Marc Glisse
convert, I can put it before if you prefer. Bootstrap+testsuite on x86_64-linux-gnu. (I believe it should also be backported to 4.8) 2013-05-06 Marc Glisse marc.gli...@inria.fr gcc/cp/ * typeck.c (cp_build_binary_op): Call save_expr before build_vector_from_val. gcc/testsuite

Re: [AArch64] Add special case when expanding vcond with arms {-1, -1}, {0, 0}.

2013-04-30 Thread Marc Glisse
arguing against this patch) -- Marc Glisse

Re: [PATCH] Loop distribution improvements

2013-04-26 Thread Marc Glisse
ping http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00336.html On Fri, 5 Apr 2013, Marc Glisse wrote: On Fri, 5 Apr 2013, Marc Glisse wrote: Shouldn't we change integer_all_onesp to do what its name says and create a separate integer_minus_onep for the single place I could find where

Re: Logic operators ! || for vectors

2013-04-26 Thread Marc Glisse
?) and to avoid ICEing on __m128i f(__m128d a,__m128d b){return abba;} as we currently do in warn_logical_operator. On Fri, 12 Apr 2013, Marc Glisse wrote: Hello, this adds support for vector !, and ||. In the long run, I think it would be good to be able to use TRUTH_*_EXPR with vectors

Re: [PATCH] Fix folding of logb (-Inf) (PR tree-optimization/57066)

2013-04-25 Thread Marc Glisse
The logb functions — logb(±0) returns −∞ and raises the ‘‘divide-by-zero’’ floating-point exception. — logb(±∞) returns ∞. -- Marc Glisse

Re: [PATCH] color diagnostics markers

2013-04-14 Thread Marc Glisse
++: error: zz.cc: No such file or directory g++: fatal error: no input files (not that it needs them, it is short enough) -- Marc Glisse

Re: [PATCH] Fix MULT_HIGHPART_EXPR folding (PR tree-optimization/56918)

2013-04-12 Thread Marc Glisse
On Fri, 12 Apr 2013, Jakub Jelinek wrote: On Thu, Apr 11, 2013 at 09:13:17PM +0200, Marc Glisse wrote: The comments on PREC in the rshift function really confused me. Yeah, me too. But if count == prec, the code always: /* Zero / sign extend all bits that are beyond the precision

Logic operators ! || for vectors

2013-04-12 Thread Marc Glisse
-scalar-2.c testcase that goes with it) should probably be backported to 4.8. The code we generate for these examples is not very good, but that's a different issue. Bootstrap+testsuite on x86_64-linux-gnu. 2013-04-12 Marc Glisse marc.gli...@inria.fr gcc/cp/ * typeck.c

Re: Logic operators ! || for vectors

2013-04-12 Thread Marc Glisse
On Fri, 12 Apr 2013, Richard Biener wrote: On Fri, Apr 12, 2013 at 11:03 AM, Marc Glisse marc.gli...@inria.fr wrote: Hello, this adds support for vector !, and ||. In the long run, I think it would be good to be able to use TRUTH_*_EXPR with vectors, but that's probably a lot of work

Fold {2, 3, 4, 5} 31

2013-04-11 Thread Marc Glisse
on x86_64-linux-gnu 2013-04-11 Marc Glisse marc.gli...@inria.fr gcc/ * fold-const.c (const_binop): Handle vector shifts by a scalar. (fold_binary_loc): Call const_binop also for mixed vector-scalar operations. gcc/testsuite/ * gcc.dg/fold-cstvecshift.c: New testcase

Re: Fold {2, 3, 4, 5} 31

2013-04-11 Thread Marc Glisse
On Thu, 11 Apr 2013, Jakub Jelinek wrote: On Thu, Apr 11, 2013 at 06:24:02PM +0200, Marc Glisse wrote: here is a patch to handle constant folding of mixed vector-integer operations. I could have shared the loop with the vector-vector case, but that would have meant re-testing if arg2

Re: [PATCH] Fix MULT_HIGHPART_EXPR folding (PR tree-optimization/56918)

2013-04-11 Thread Marc Glisse
; + check_vect (); + for (i = 0; i 15; ++i) +a[i] = (i * 2) % 15; + for (i = 0; i 15; ++i) +if (a[i] != (i * 2) % 15) + abort (); + return 0; +} + +/* { dg-final { cleanup-tree-dump vect } } */ Jakub -- Marc Glisse

Re: [i386] Replace builtins with vector extensions

2013-04-09 Thread Marc Glisse
On Tue, 9 Apr 2013, Richard Biener wrote: On Mon, Apr 8, 2013 at 10:47 PM, Marc Glisse marc.gli...@inria.fr wrote: On Sun, 7 Apr 2013, Marc Glisse wrote: extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, __artificial__)) _mm_slli_epi16 (__m128i __A, int __B

Re: [i386] Replace builtins with vector extensions

2013-04-09 Thread Marc Glisse
On Tue, 9 Apr 2013, Jakub Jelinek wrote: On Tue, Apr 09, 2013 at 11:08:38AM +0200, Marc Glisse wrote: The *intrin.h files already use __extension__ to create vectors, like: return __extension__ (__m128d){ __F, 0.0 }; but even when I remove it it does not warn with -std=c89 -pedantic. Even

Re: [i386] Replace builtins with vector extensions

2013-04-09 Thread Marc Glisse
On Tue, 9 Apr 2013, Marc Glisse wrote: On Tue, 9 Apr 2013, Richard Biener wrote: I seem to remember discussion in the PR(s) that the intrinsics should (and do for other compilers) expand to the desired instructions even when the corresponding instruction set is disabled. emmintrin.h starts

Re: useless cast blocking some optimization in gcc 4.7.3

2013-04-08 Thread Marc Glisse
). However, your transformation turns it into undefined behavior: an addition that overflows in a type with TYPE_OVERFLOW_UNDEFINED. -- Marc Glisse

Re: [i386] Replace builtins with vector extensions

2013-04-08 Thread Marc Glisse
On Sun, 7 Apr 2013, Marc Glisse wrote: extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, __artificial__)) _mm_slli_epi16 (__m128i __A, int __B) { - return (__m128i)__builtin_ia32_psllwi128 ((__v8hi)__A, __B); + return (__m128i) ((__v8hi)__A __B); } Actually, I

[i386] Replace builtins with vector extensions

2013-04-07 Thread Marc Glisse
. * For integer operations like _mm_add_epi16 I should probably use the unsigned typedefs to make it clear overflow is well defined? (the patch still has the signed version) * Any better name than __v4su for the unsigned version of __v4si? * Other comments? 2013-04-07 Marc Glisse marc.gli

Re: [i386] Replace builtins with vector extensions

2013-04-07 Thread Marc Glisse
By the way, the comment in emmintrin.h in front of _mm_sqrt_sd seems wrong: /* Return pair {sqrt (A[0), B[1]}. */ It should be instead: /* Return pair {sqrt (B[0]), A[1]}. */ If you agree I'll fix that independently. -- Marc Glisse

Re: [PATCH] Loop distribution improvements

2013-04-05 Thread Marc Glisse
where it would break, the folding of x * -1 ? -- Marc Glisse

Re: [PATCH] Loop distribution improvements

2013-04-05 Thread Marc Glisse
On Fri, 5 Apr 2013, Marc Glisse wrote: Shouldn't we change integer_all_onesp to do what its name says and create a separate integer_minus_onep for the single place I could find where it would break, the folding of x * -1 ? 2013-04-05 Marc Glisse marc.gli...@inria.fr * tree.c

Re: Fold BIT_FIELD_REF of a reference

2013-04-04 Thread Marc Glisse
On Wed, 3 Apr 2013, Richard Biener wrote: On Wed, Apr 3, 2013 at 4:15 PM, Marc Glisse marc.gli...@inria.fr wrote: Hello, I am not 100% convinced that it is always better to fold to a MEM_REF, but that's what the PR asks for. bootstrap+testsuite on x86_64-linux-gnu. 2013-04-03 Marc Glisse

Re: Fold BIT_FIELD_REF of a reference

2013-04-04 Thread Marc Glisse
for ADDR_EXPR: is_gimple_address (t) unexpected expression 'v' of kind mem_ref in cxx_eval_constant_expression The first one in particular affects almost all vector tests, so it might hide other issues. -- Marc Glisse

Re: Fold BIT_FIELD_REF of a reference

2013-04-04 Thread Marc Glisse
On Thu, 4 Apr 2013, Richard Biener wrote: On Thu, Apr 4, 2013 at 10:53 AM, Marc Glisse marc.gli...@inria.fr wrote: On Thu, 4 Apr 2013, Richard Biener wrote: + if ((handled_component_p (arg0) || TREE_CODE (arg0) == MEM_REF) This check means the optimization is not performed

Fold BIT_FIELD_REF of a reference

2013-04-03 Thread Marc Glisse
Hello, I am not 100% convinced that it is always better to fold to a MEM_REF, but that's what the PR asks for. bootstrap+testsuite on x86_64-linux-gnu. 2013-04-03 Marc Glisse marc.gli...@inria.fr PR middle-end/52436 gcc/ * fold-const.c (fold_ternary_loc) BIT_FIELD_REF

Re: [rtl, i386] vec_merge simplification

2013-04-02 Thread Marc Glisse
. Thanks, I should have checked the other uses indeed... I got confused because at tree level, operand_equal_p implies that there are no side effects. -- Marc Glisse

Re: [RTL] Canonicalize commutative operations more

2013-04-02 Thread Marc Glisse
), that the canonicalization would make more noticable (and thus easier to fix). -- Marc Glisse

Re: RFC: add some static probes to libstdc++

2013-04-02 Thread Marc Glisse
we update the prerequisites documentation to say that if Systemtap is installed it needs to be at least version X? I thought you were going to suggest enhancing the configure test so it fails on old systemtap (detects it as absent). -- Marc Glisse

Re: [rtl, i386] vec_merge simplification

2013-04-01 Thread Marc Glisse
, shouldn't this be: unsigned HOST_WIDE_INT mask = ((unsigned HOST_WIDE_INT) 2 (n_elts - 1)) - 1; so it doesn't cause undefined behavior for V64QI? -- Marc Glisse

Re: SLP for vectors

2013-04-01 Thread Marc Glisse
On Sat, 30 Mar 2013, Marc Glisse wrote: * tree-flow-inline.h (get_addr_base_and_unit_offset_1): Handle BIT_FIELD_REF. I wrote a safer version of this for PR52436: case BIT_FIELD_REF: - return NULL_TREE; + { + HOST_WIDE_INT this_off

Re: C++ PATCH: use C++ semantics for inline functions (defined in headers)

2013-03-31 Thread Marc Glisse
throughout the compiler? I didn't check if the cxx-conversion branch already does it. -- Marc Glisse

Constant folding of VEC_COND_EXPR

2013-03-31 Thread Marc Glisse
better to add it at the same time. bootstrap+testsuite on x86_64-linux-gnu. 2013-03-31 Marc Glisse marc.gli...@inria.fr PR tree-optimization/56790 * fold-const.c (fold_ternary_loc) VEC_COND_EXPR: Add constant folding. testsuite/ * g++.dg/ext/pr56790-1.C: New testcase

Re: Constant folding of VEC_COND_EXPR

2013-03-31 Thread Marc Glisse
On Sun, 31 Mar 2013, Andrew Pinski wrote: On Sun, Mar 31, 2013 at 6:31 AM, Marc Glisse marc.gli...@inria.fr wrote: Hello, this adds constant folding of VEC_COND_EXPR at the tree level by forwarding to the VEC_PERM_EXPR code (a merge is a special case of a permutation). The CONSTRUCTOR case

Re: [RTL] Canonicalize commutative operations more

2013-03-30 Thread Marc Glisse
versions), I am just as happy with that. By the way, even if we don't take the canonicalization (just ignore the line comparing GET_CODEs), do we still want the refactoring that this patch brings, or is the current interface better? -- Marc Glisse

Re: [rtl, i386] vec_merge simplification

2013-03-30 Thread Marc Glisse
(op0, op1), but I am still doing it as it seems safe. Uros, are you ok with the testsuite part? 2013-03-30 Marc Glisse marc.gli...@inria.fr gcc/ * simplify-rtx.c (simplify_binary_operation_1) VEC_SELECT: Handle VEC_MERGE. (simplify_ternary_operation) VEC_MERGE: Use

Re: SLP for vectors

2013-03-30 Thread Marc Glisse
(the base object is not computed for SLP) but shouldn't hurt. The current patch is attached (passed bootstrap+testsuite a week ago). Are there some parts of this that could go in? 2013-03-30 Marc Glisse marc.gli...@inria.fr * tree-vect-stmts.c (vectorizable_store): Accept

Re: [RTL, i386] Use subreg instead of UNSPEC_CAST

2013-03-20 Thread Marc Glisse
On Tue, 19 Mar 2013, Richard Henderson wrote: On 03/19/2013 08:47 AM, Marc Glisse wrote: (define_insn_and_split avx_castmodeavxsizesuffix_castmode [(set (match_operand:AVX256MODE2P 0 nonimmediate_operand =x,m) - (unspec:AVX256MODE2P - [(match_operand:ssehalfvecmode 1

Re: [RTL, i386] Use subreg instead of UNSPEC_CAST

2013-03-20 Thread Marc Glisse
On Wed, 20 Mar 2013, Richard Henderson wrote: On 03/20/2013 08:00 AM, Marc Glisse wrote: Do you at least agree that vector-vector subregs make sense, or is that part wrong as well? You mean a V4SImode subreg of a V8SImode register, not just same-size casting? I am mostly interested

Re: [RTL, i386] Use subreg instead of UNSPEC_CAST

2013-03-20 Thread Marc Glisse
On Wed, 20 Mar 2013, Richard Biener wrote: On Wed, Mar 20, 2013 at 4:29 PM, Marc Glisse marc.gli...@inria.fr wrote: On Wed, 20 Mar 2013, Richard Henderson wrote: On 03/20/2013 08:00 AM, Marc Glisse wrote: Do you at least agree that vector-vector subregs make sense, or is that part wrong

Re: Fold VEC_COND_EXPR to abs, min, max

2013-03-19 Thread Marc Glisse
Hello, new version of the patch. Note that for the simplification from {-1,-1}?a:b to a, I removed the test that b has no side effects and call pedantic_omit_one_operand_loc instead. Bootstrap + testsuite on x86_64-linux-gnu. 2013-03-19 Marc Glisse marc.gli...@inria.fr gcc

[RTL, i386] Use subreg instead of UNSPEC_CAST

2013-03-19 Thread Marc Glisse
Hello, the following patch passes bootstrap+testsuite on x86_64-linux-gnu. I don't see any particular reason to forbid vector subregs of vectors, since we can already do it through a scalar. And not using unspecs helps avoid unnecessary copies. 2013-01-03 Marc Glisse marc.gli...@inria.fr

Re: i * i is nonnegative

2013-03-19 Thread Marc Glisse
On Tue, 19 Mar 2013, Jeff Law wrote: On 03/19/2013 10:08 AM, Marc Glisse wrote: Hello, this patch extends the property that x*x is non-negative, which was already known for floats, to integers with undefined overflow. 2013-03-19 Marc Glisse marc.gli...@inria.fr PR tree-optimization

[RTL] Canonicalize commutative operations more

2013-03-19 Thread Marc Glisse
on the arbitrary order). I am not sure that is the best place to break the recursion, but it seems to work. I don't really expect the patch to be accepted as is, but it seems good enough to start the conversation. 2013-03-19 Marc Glisse marc.gli...@inria.fr PR rtl-optimization/55611

Re: Fold VEC_COND_EXPR to abs, min, max

2013-03-18 Thread Marc Glisse
On Mon, 18 Mar 2013, Richard Biener wrote: 2013-03-17 Marc Glisse marc.gli...@inria.fr gcc/ * fold-const.c (fold_cond_expr_with_comparison): Use build_zero_cst. VEC_COND_EXPR cannot be lvalues. (fold_ternary_loc) VEC_COND_EXPR: Call fold_cond_expr_with_comparison

Re: Fold VEC_COND_EXPR to abs, min, max

2013-03-18 Thread Marc Glisse
On Mon, 18 Mar 2013, Richard Biener wrote: On Mon, Mar 18, 2013 at 11:27 AM, Marc Glisse marc.gli...@inria.fr wrote: On Mon, 18 Mar 2013, Richard Biener wrote: You mean that the VEC_COND_EXPRs can never be used as an lvalue in the C++ frontend? Yes, as I mention in the ChangeLog. Not just

Fold VEC_COND_EXPR to abs, min, max

2013-03-17 Thread Marc Glisse
copied the most relevant block. Folding from the front-end is ugly, but that's how the scalar case works, and they can both move to gimple folding together later. Bootstrap + testsuite on x86_64-linux-gnu. 2013-03-17 Marc Glisse marc.gli...@inria.fr gcc/ * fold-const.c

Re: [rtl] combine a vec_concat of 2 vec_selects from the same vector

2013-03-16 Thread Marc Glisse
advantage of it, that's probably a bit questionable indeed. Thank you for the comment. I successfully regtested the attached trivial patch on x86_64-linux-gnu: 2013-03-16 Marc Glisse marc.gli...@inria.fr * simplify-rtx.c (simplify_binary_operation_1) VEC_CONCAT: Restrict

[rtl, i386] vec_merge simplification

2013-03-16 Thread Marc Glisse
reuse this operand. If not, I probably got the patch wrong. int is getting small to store one bit per vector element (V32QI...) so I switched to hwint after checking that Zadeck's patches don't touch this. Bootstrap + testsuite on x86_64-linux-gnu. 2013-03-17 Marc Glisse marc.gli

Re: [rtl] combine a vec_concat of 2 vec_selects from the same vector

2013-03-15 Thread Marc Glisse
On Sun, 30 Sep 2012, Marc Glisse wrote: On Sat, 29 Sep 2012, Eric Botcazou wrote: this patch lets the compiler try to rewrite: (vec_concat (vec_select x [a]) (vec_select x [b])) as: vec_select x [a b] or even just x if appropriate. [...] Why not generalizing to all kinds of VEC_SELECTs

Re: [cxx-conversion] RFC - Helper types for building GIMPLE

2013-03-14 Thread Marc Glisse
and having a single gimplification call at the end (the time wasted should be quite limited). (Note that I encourage the efforts to simplify the gimple interface, I am just taking the occasion to ask a vaguely related question) -- Marc Glisse

Re: [C++11][4.9] Add missing REDUC_PLUS_EXPR case to potential_constant_expression_1.

2013-03-14 Thread Marc Glisse
with myriads of weird tree codes etc. isn't IMHO desirable. Wouldn't that prevent from using those builtins in constant expressions? That seems undesirable. Maybe an alternative could be to push some of the functionality from potential_constant_expression_1 to the middle-end? -- Marc Glisse

Keep the macro complex in C++03

2013-02-13 Thread Marc Glisse
Hello, this patch was tested on x86_64-linux-gnu. For the testcase, I randomly picked c99.cc which I copied and c++11 - c++98, _Complex - complex, but anything using the macro would do. 2013-02-13 Marc Glisse marc.gli...@inria.fr PR libstdc++/56111 * include/std/complex

Document ?: for vectors

2013-02-13 Thread Marc Glisse
) is another argument in this direction. On the other hand, it is there, we might as well document it. 2013-02-13 Marc Glisse marc.gli...@inria.fr * doc/extend.texi (Vector Extensions): Document ?: in C++. -- Marc GlisseIndex: gcc/doc/extend.texi

Re: [PATCH] Fix bootstrap with -O3

2013-02-09 Thread Marc Glisse
): Initialize to NULL. Maybe mention PR44938? (there may be a dup or two) (I thought it was the name of the function that went inside the parentheses in a ChangeLog entry) -- Marc Glisse

Re: SLP for vectors

2013-01-30 Thread Marc Glisse
On Tue, 29 Jan 2013, Richard Biener wrote: On Sun, Jan 27, 2013 at 4:28 PM, Marc Glisse marc.gli...@inria.fr wrote: Hello, this message is to check that I am not doing something absurd and ask for a bit of advice. In the attached patch, I let SLP recognize vector loads/stores just like

Re: [PATCH] Fix up pow folding (PR tree-optimization/56125)

2013-01-28 Thread Marc Glisse
in the testsuite? The testcase now generates a library call to pow, like gcc-4.6. This is correct, but I am surprised this is considered better than leaving the original x/(n*n) unchanged... Should that be a different PR? -- Marc Glisse

<    8   9   10   11   12   13   14   15   16   >