Re: [PATCH], PR target/81593, Optimize PowerPC vector sets coming from a vector extracts

EC_PERM_EXPR? For this last part, we have simplify_vector_constructor in tree-ssa-forwprop.c, which currently only recognizes VEC_PERM_EXPR of a single vector, but I guess it could be extended to 2 vectors. Not as good as a bswap revamp (which will be needed anyway at some point), but less work. -- Marc Glisse

Re: [PATCH GCC][1/2]Feed bound computation to folder in loop split

On Wed, 26 Jul 2017, Richard Sandiford wrote: Marc Glisse <marc.gli...@inria.fr> writes: On Wed, 26 Jul 2017, Richard Sandiford wrote: Richard Biener <richard.guent...@gmail.com> writes: On Tue, Jul 25, 2017 at 7:45 PM, Marc Glisse <marc.gli...@inria.fr> wrote: On Tue, 25

Re: [PATCH GCC][1/2]Feed bound computation to folder in loop split

On Wed, 26 Jul 2017, Richard Sandiford wrote: Richard Biener <richard.guent...@gmail.com> writes: On Tue, Jul 25, 2017 at 7:45 PM, Marc Glisse <marc.gli...@inria.fr> wrote: On Tue, 25 Jul 2017, Richard Biener wrote: I think we need Richard to say what the intent is for the

Re: [PATCH GCC][1/2]Feed bound computation to folder in loop split

hich tries to valueize, but if it gets a NULL_TREE, it returns its argument unchanged. Not very confident about it though. -- Marc Glisse

Re: [PATCH GCC][1/2]Feed bound computation to folder in loop split

On Mon, 24 Jul 2017, Bin.Cheng wrote: On Mon, Jul 24, 2017 at 3:31 PM, Marc Glisse <marc.gli...@inria.fr> wrote: On Mon, 24 Jul 2017, Bin.Cheng wrote: On Mon, Jul 24, 2017 at 2:59 PM, Marc Glisse <marc.gli...@inria.fr> wrote: On Mon, 24 Jul 2017, Bin.Cheng wrote: But sinc

Re: [PATCH GCC][1/2]Feed bound computation to folder in loop split

On Mon, 24 Jul 2017, Bin.Cheng wrote: On Mon, Jul 24, 2017 at 2:59 PM, Marc Glisse <marc.gli...@inria.fr> wrote: On Mon, 24 Jul 2017, Bin.Cheng wrote: But since definition of _197 isn't in current stmt sequence, call "o31 = do_valueize (valueize, o31)" will return NULL. A

Re: [PATCH GCC][1/2]Feed bound computation to folder in loop split

;in the current generic tree" and why isn't it "in current stmt sequence"? -- Marc Glisse

Re: [PATCH GCC][1/2]Feed bound computation to folder in loop split

very similar issue a few weeks ago, don't know if he found a solution. You could call gimple_simplify directly with a different valueization function if that's safe. Normally the simplification would wait until the next forwprop pass. -- Marc Glisse

Re: [PATCH] PR libstdc++/81476 Optimise vector insertion from input iterators

. That uses random access iterators, so we know how far to move the existing elements and can just move them to their final position in one step. Is it legal to use the allocator even though capacity-size is large enough for the inserted range? -- Marc Glisse

Re: [PATCH] Implement one optimization from build_range_check in match.pd (PR tree-optimization/81346)

On Tue, 18 Jul 2017, Jakub Jelinek wrote: On Tue, Jul 18, 2017 at 05:35:54PM +0200, Marc Glisse wrote: On Tue, 18 Jul 2017, Jakub Jelinek wrote: In the PR Marc noted that the optimization might be useful even for constants other than 1, by transforming x+C1 <= C2 if unsigned and C2

Re: [PATCH] Implement one optimization from build_range_check in match.pd (PR tree-optimization/81346)

hall we also change build_range_check to do that (i.e. drop the integer_onep above and use right etype constant? I would rather consider build_range_check legacy and avoid modifying it too much, but if you are motivated... + && TYPE_PRECISION (TREE_TYPE (@0)) > 1 I see you've been b

Re: [PATCH] Move fold_div_compare optimization to match.pd (PR tree-optimization/81346)

that etype is always unsigned and since you check the input (doesn't hurt though). + (if (code == EQ_EXPR) + (le (minus (convert:etype @0) { lo; }) { hi; }) + (gt (minus (convert:etype @0) { lo; }) { hi; }) -- Marc Glisse

Re: [PATCH] match.pd: reassociate multiplications with constants

On Sat, 15 Jul 2017, Alexander Monakov wrote: On Thu, 13 Jul 2017, Marc Glisse wrote: X*big*big where abs(big*big)>abs(INT_MIN) can be optimized to 0 I'm not sure that would be a win, eliminating X prevents the compiler from deducing that X must be zero (if overflow invokes undefi

Re: [PATCH 2/3] Simplify wrapped binops

verflows at runtime. (It looks like you don't need to name @3, you could just use the type of @0 instead) -- Marc Glisse

Re: [PATCH] match.pd: reassociate multiplications with constants

On Thu, 13 Jul 2017, Alexander Monakov wrote: On Thu, 13 Jul 2017, Marc Glisse wrote: I notice that we do not turn (X*10)*10 into X*100 in GIMPLE. Sorry, could you clarify what you mean here? I think we certainly do that, just not via match.pd, but in 'associate:' case of fold_binary_loc

Re: [PATCH] match.pd: reassociate multiplications with constants

s :s on the inner multiplication. Unless the test on TYPE_OVERFLOW_SANITIZED etc is shared with adjacent transformations, I'd rather put it inside, with the other if, but that's a matter of taste. One small testcase please? Or is there already one that is currently failing? (I cannot ok patches, only

Re: [RFC/SCCVN] Handle BIT_INSERT_EXPR in vn_nary_op_eq

need a few such special cases. But shouldn't the hash function be in sync with the equality comparator? Does operand_equal_p need the same? -- Marc Glisse

Re: [PATCH][PR 57371] Remove useless floating point casts in comparisons

at it is INTEGRAL_TYPE_P (or VECTOR_INTEGER_TYPE_P but then the result would have to be VECTOR_FLOAT_TYPE_P, and since it gets compared to REAL_CST... the test SCALAR_FLOAT_TYPE_P is actually redundant). -- Marc Glisse

Re: [PATCH][PR 57371] Remove useless floating point casts in comparisons

On Sun, 2 Jul 2017, Yuri Gribov wrote: On Sun, Jul 2, 2017 at 6:32 PM, Marc Glisse <marc.gli...@inria.fr> wrote: On Sun, 2 Jul 2017, Yuri Gribov wrote: This is initial patch for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57371 . Thanks. I have had this unfinished, probably wrong

Re: [PATCH][PR 57371] Remove useless floating point casts in comparisons

On Sun, 2 Jul 2017, Yuri Gribov wrote: This is initial patch for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57371 . Thanks. I have had this unfinished, probably wrong patch on my hard drive for 4 years, I doubt there is much you can extract from it, but just in case... -- Marc

Re: [RFC PATCH] Fix pointer diff (was: -fsanitize=pointer-overflow support (PR sanitizer/80998))

On Thu, 22 Jun 2017, Richard Biener wrote: On Thu, 22 Jun 2017, Marc Glisse wrote: On Thu, 22 Jun 2017, Richard Biener wrote: If we consider pointers as unsigned, with a subtraction that has a signed result with the constraint that overflow is undefined, we cannot model that optimally

Re: C++ PATCH for c++/69300, ICE with self-referential noexcept

ept. Then we get into solving the same thing as IPA already does... And the standard does not require implementations to be clever there. Still, it could have been nice :-/ -- Marc Glisse

Re: Simple reassoc transforms in match.pd

On Mon, 26 Jun 2017, Richard Biener wrote: On Fri, Jun 23, 2017 at 3:12 PM, Marc Glisse <marc.gli...@inria.fr> wrote: Hello, here are a few simple transformations, mostly useful for types with undefined overflow where we do not have reassoc. I did not name the testcase reassoc-* to

Re: Simplify 3*x == 3*y for wrapping types

On Mon, 26 Jun 2017, Richard Biener wrote: I think the mults don't need :c as we should canonicalize the constant to 2nd operand. Oups, I copied the transformation above (which does need :c) and didn't notice it was there. Good catch, thanks. -- Marc Glisse

Re: [PATCH] Fold (a > 0 ? 1.0 : -1.0) into copysign (1.0, a) and a * copysign (1.0, a) into abs(a)

+ +/* Transform copysign (-1.0, X) into copysign (1.0, X). */ +(simplify + (COPYSIGN real_minus_onep @0) + (COPYSIGN { build_one_cst (type); } @0)) (simplify (COPYSIGN REAL_CST@0 @1) (if (REAL_VALUE_NEGATIVE (TREE_REAL_CST (@0))) (COPYSIGN (negate @0) @1))) ? Or does that create trouble with sNaN and only the 1.0 case is worth the trouble? -- Marc Glisse

Re: [PATCH] fold a * (a > 0 ? 1 : -1) to abs(a) and related optimizations

without this change, I only wanted to raise the question in case someone knows. -- Marc Glisse

Simplify 3*x == 3*y for wrapping types

-06-26 Marc Glisse <marc.gli...@inria.fr> gcc/ * match.pd ((X & ~Y) | (~X & Y)): Generalize to + and ^. (x * C EQ/NE y * C): New transformation. gcc/testsuite/ * gcc.dg/tree-ssa/addadd.c: Remove test duplicated in addadd-2.c. * gcc.dg/tree-ssa/mulcmp

Re: [PATCH] fold a * (a > 0 ? 1 : -1) to abs(a) and related optimizations

# prephitmp_6 = PHI <a_2(D)(2), _5(3)> which phiopt3 can handle (quite late). * With cond, this currently (?) only affects generic, so I am not sure it will hit very often... But it will be there if someone later writes a match.pd->phiopt generator ;-) -- Marc Glisse

fenv.h builtins

convinced there is much we will be able to do with those, but at least they are available now... Trying to declare those functions with wrong prototypes now gives the expected error. Bootstrap + testsuite on powerpc64le-unknown-linux-gnu. 2017-06-23 Marc Glisse <marc.gli...@inria.fr>

Re: [PATCH] Fix PR81175, make gather builtins pure

If you svn update (or equivalent), you will notice that the above is already available ;-) -- Marc Glisse

Simple reassoc transforms in match.pd

+ testsuite on powerpc64le-unknown-linux-gnu. 2017-06-23 Marc Glisse <marc.gli...@inria.fr> gcc/ * match.pd ((A+-B)+(C-A), (A+B)-(A-C)): New transformations. gcc/testsuite/ * gcc.dg/tree-ssa/assoc-1.c: New file. -- Marc GlisseIndex: gcc/ma

Re: Refactor fileptr_type_node handling

On Thu, 22 Jun 2017, Richard Biener wrote: On Thu, Jun 22, 2017 at 12:58 PM, Marc Glisse <marc.gli...@inria.fr> wrote: On Thu, 22 Jun 2017, Richard Biener wrote: On Thu, Jun 22, 2017 at 10:46 AM, Marc Glisse <marc.gli...@inria.fr> wrote: Hello, I was asked to handle (c

Re: Refactor fileptr_type_node handling

On Thu, 22 Jun 2017, Richard Biener wrote: On Thu, Jun 22, 2017 at 10:46 AM, Marc Glisse <marc.gli...@inria.fr> wrote: Hello, I was asked to handle (const) fenv_t and fexcept_t the same way as FILE and const tm. Since these have special handling in quite a few places, it seems nec

Re: [RFC PATCH] Fix pointer diff (was: -fsanitize=pointer-overflow support (PR sanitizer/80998))

... We usually do those multiplications in an unsigned type. I experimented with changing one such place in https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01641.html , there is probably at least another one in the middle-end. -- Marc Glisse

Refactor fileptr_type_node handling

+ testsuite on powerpc64le-unknown-linux-gnu. 2017-06-22 Marc Glisse <marc.gli...@inria.fr> gcc/ * tree.h (predeclared_type): New type. (predeclared_types): Declare new array. * tree.c (predeclared_types): New array. (free_lang_data, build_common_tree_nodes

Re: [RFC PATCH] Fix pointer diff (was: -fsanitize=pointer-overflow support (PR sanitizer/80998))

erence in match.pd (it is recursive so a complete move may be harder). But that would make your patch break even more stuff :-( -- Marc Glisse

Re: [i386] __builtin_ia32_stmxcsr could be pure

Ping. On Sat, 3 Jun 2017, Marc Glisse wrote: Hello, I don't think Richard's "sounds good" was meant as "ok to commit". Does an x86 maintainer want to approve or criticize the patch? https://gcc.gnu.org/ml/gcc-patches/2017-05/msg02009.html On Fri, 26 May 2017,

NOP conversions in X+CST+CST

. It still shouldn't interfere with the patch by Robin Dapp which IIUC only handles the case where the conversion is an extension. 2017-06-21 Marc Glisse <marc.gli...@inria.fr> gcc/ * match.pd (nop_convert): New predicate. ((A +- CST1) +- CST2): Allow some NOP conversions

Re: Prevent infinite recursion between simplification and CSE in FRE

On Mon, 19 Jun 2017, Richard Biener wrote: On Sat, Jun 17, 2017 at 9:35 AM, Marc Glisse <marc.gli...@inria.fr> wrote: Hello, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80887#c10 for the context. FRE can go into an infinite recursion with some match.pd simplifications (that hav

Prevent infinite recursion between simplification and CSE in FRE

100); if (!d) return false; for instance. 100 was picked arbitrarily, I don't think it is worth having a param for it, but we could certainly use a different value. Bootstrap and testsuite on powerpc64le-unknown-linux-gnu. 2017-06-19 Marc Glisse <marc.gli...@inria.fr> * gimple-mat

Re: [PATCH GCC][1/2]Feed bound computation to folder in loop split

t_cst_sgn (@1) > 0) @0 @2))) What is the type of all those SSA_NAMEs? -- Marc Glisse

Re: [PATCH] handle bzero/bcopy in DSE and aliasing (PR 80933, 80934)

*. Joseph? The patch optimizes __builtin_bzero, which should be ok. The question (independent from this patch) is then under what conditions bzero should be detected as a builtin. -- Marc Glisse

Re: [PATCH] vec_merge + vec_duplicate + vec_concat simplification

that guarantees we cannot get (vec_merge (vec_concat (y) (z)) (vec_duplicate x) (const_int N)) ? I was wondering if it would be possible to merge the transformations for concat and duplicate into a single one, but maybe it becomes too unreadable. -- Marc Glisse

Re: [PATCH] Optimize std::advance for single increments

a new overload to do that, and here's the proof. This performs the same optimisation when the argument to __advance is known at compile-time to be +1 or -1, as is the case when called from std::next(i) or std::prev(i). Do you want to optimize the case __n == 0 as well? ;-) -- Marc Glisse

Re: [i386] __builtin_ia32_stmxcsr could be pure

Hello, I don't think Richard's "sounds good" was meant as "ok to commit". Does an x86 maintainer want to approve or criticize the patch? https://gcc.gnu.org/ml/gcc-patches/2017-05/msg02009.html On Fri, 26 May 2017, Richard Biener wrote: On Fri, May 26, 2017 at 1

Re: builtin fenv functions

odeling dependences between FP ops and the FP control/exception registers. Yes, I didn't expect adding those 5 builtins (modulo the nothrow flag) to be controversial... -- Marc Glisse

Re: Allow some NOP conversions in (X+CST1)+CST2 in match.pd

On Sat, 27 May 2017, Jakub Jelinek wrote: After discussions in PR80887, I've reverted the match.pd part and xfailed the test, because it breaks bootstrap and will take a while to resolve properly. Thank you. -- Marc Glisse

Re: builtin fenv functions

On Fri, 26 May 2017, Richard Biener wrote: On Fri, May 26, 2017 at 11:52 AM, Marc Glisse <marc.gli...@inria.fr> wrote: Hello, coming back to https://gcc.gnu.org/ml/gcc-patches/2014-02/msg01378.html , Richard wanted a complete set of fenv functions instead of just the 2 I was inte

builtin fenv functions

). We can then discuss the safety of future optimizations on a case by case basis. 2017-05-29 Marc Glisse <marc.gli...@inria.fr> * builtins.def (BUILT_IN_FECLEAREXCEPT, BUILT_IN_FEGETROUND, BUILT_IN_FERAISEEXCEPT, BUILT_IN_FESETROUND, BUILT_IN_FETESTEXCEPT): New bu

[i386] __builtin_ia32_stmxcsr could be pure

(like "const" already has) since there should be other builtins that can be marked this way (maybe the gathers?). Bootstrap+testsuite on x86_64-pc-linux-gnu with default languages. 2017-05-29 Marc Glisse <marc.gli...@inria.fr> gcc/ * config/i386/i386.c (struct builtin

Relax VIEW_CONVERT_EXPR - CONVERT_EXPR combination

I hope this is safe. Bootstrap+testsuite on powerpc64le-unknown-linux-gnu. 2017-05-22 Marc Glisse <marc.gli...@inria.fr> gcc/ * match.pd (view_convert (convert@0 @1)): Handle zero-extension. gcc/testsuite/ * gcc.dg/tree-ssa/vce-1.c: New file. -- Marc GlisseInd

signed multiplication for pointer offsets

Hello, when we have a double*p, computing p+n, we multiply n by 8 (size of double) then add it to p. According to the comment just below the modified lines in the attached patch, the multiplication is supposed to happen in a signed type. However, that does not match the current code which

Allow some NOP conversions in (X+CST1)+CST2 in match.pd

. Bootstrap+testsuite on powerpc64le-unknown-linux-gnu. 2017-05-22 Marc Glisse <marc.gli...@inria.fr> gcc/ * match.pd ((A +- CST1) +- CST2): Allow some conversions. * tree.c (drop_tree_overflow): Handle COMPLEX_CST and VECTOR_CST. gcc/testsuite/ * gcc.dg/tree-ssa/ad

Move "(A & C) == D is false when D & ~C != 0" to match.pd

clearer. Bootstrap+testsuite on powerpc64le-unknown-linux-gnu. 2017-05-22 Marc Glisse <marc.gli...@inria.fr> * fold-const.c (fold_binary_loc) [(A & C) == D]: Remove transformation. * match.pd (X == C): Rewrite it here. (with_possible_no

Move X==15-X to match.pd

; C) == D where D & ~C != 0, convert this into 0." because it is already handled by CCP. Would that be ok or does it still need an equivalent match.pd version? Bootstrap+testsuite on powerpc64le-unknown-linux-gnu. 2017-05-18 Marc Glisse <marc.gli...@inria.fr> * fold-

Re: Default std::vector default and move constructor

)+1)*8 --> n+8 when the division is known to be exact -- Marc Glisse

Re: Default std::vector default and move constructor

. -- Marc Glisse

[libstdc++] Assertion in optional

on powerpc64le-unknown-linux-gnu. 2017-05-15 Marc Glisse <marc.gli...@inria.fr> * include/std/optional (_Optional_base::_M_get): Check precondition. * testsuite/20_util/optional/cons/value_neg.cc: Update line numbers. -- Marc GlisseIndex: include/std/op

Re: [c++ PATCH] PR c++/80682

dg/ext/is_trivially_constructible1.C: Add tests for void target. What happens for "const void" and other variants? -- Marc Glisse

Re: [PATCH, RFC] warn about raw pointers that can be unique_ptr

On Sun, 7 May 2017, Trevor Saunders wrote: On Sun, May 07, 2017 at 07:32:48PM +0200, Marc Glisse wrote: On Sun, 7 May 2017, tbsaunde+...@tbsaunde.org wrote: This is a start at warning about various resource allocation issues that can be improved. Currently it only warns about functions

Re: [PATCH, RFC] warn about raw pointers that can be unique_ptr

and such an optimization? Or are the goals likely to diverge too soon for sharing to be practical? -- Marc Glisse

Re: Bug in GCC 7.1?

e a problem with gcc, maybe optimization creates a path that corresponds to size==0 and fails to notice that it cannot be taken. -- Marc Glisse

Re: Support Library Requirements for GCC 7.1

build recipe: %define mpfr_version 2.4.2 %define mpc_version0.8.1 %define gmp_version4.3.2 I tried that with gcc 7.1.0 but the build failed complaining mpfr was too old. Could you be more precise about how the build failed? AFAIK mpfr-2.4.2 is still supposed to work. -- Marc Glisse

Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts

issue came up, and Ada folks asked us to keep the builtins... -- Marc Glisse

Re: [PATCH GCC8][22/33]Generate TMR in new reassociation order

ious version. This isn't a context diff. Thanks for reviewing. I used git diff -U20 to generate patch. Maybe 20 is too small? See option -c (instead of -u) in man diff. -- Marc Glisse

Re: [PATCH] PR libstdc++/80553 don't allow destroying non-destructible types

, even those with iterators much more complicated than vector's? I'd rather keep the special code in the library, if it doesn't cause too much trouble. -- Marc Glisse

Re: Add st[pr]ncpy to stmt_kills_ref_p

On Sun, 30 Apr 2017, Martin Sebor wrote: On 04/29/2017 01:17 AM, Marc Glisse wrote: Hello, this patch seems rather trivial, once one knows that those functions always write exactly n characters (they fill with 0 as needed at the end). Nice! Now it just needs to be made to work the other

Add st[pr]ncpy to stmt_kills_ref_p

Hello, this patch seems rather trivial, once one knows that those functions always write exactly n characters (they fill with 0 as needed at the end). Bootstrap+regtest on powerpc64le-unknown-linux-gnu. 2017-05-02 Marc Glisse <marc.gli...@inria.fr> PR tree-optimization/804

Re: Drop Z from X + Z < Y + Z

On Fri, 28 Apr 2017, Richard Biener wrote: On Fri, Apr 28, 2017 at 1:35 PM, Marc Glisse <marc.gli...@inria.fr> wrote: Hello, surprisingly, this did not cause any Wstrict-overflow failure. Some of it sounds more like reassoc's job, but it is convenient to handle simple cases in match

Drop Z from X + Z < Y + Z

ned types. I may still be able to remove the divisions, I'll see if I can sprinkle some 'convert' in recent transformations. Bootstrap+regtest on powerpc64le-unknown-linux-gnu. 2017-04-28 Marc Glisse <marc.gli...@inria.fr> gcc/ * match.pd (X+Z CMP Y+Z, X-Z CMP Y-Z, Z-X CMP

Re: std::vector move assign patch

as free/delete, deallocate can only be called with something allocate returned, not 0. So we don't have a choice. -- Marc Glisse

Re: std::vector move assign patch

On Tue, 25 Apr 2017, Jonathan Wakely wrote: On 25/04/17 17:23 +0200, Marc Glisse wrote: On Tue, 25 Apr 2017, Jonathan Wakely wrote: On 24/04/17 22:10 +0200, Marc Glisse wrote: It seems that this patch had 2 consequences that may or may not have been planned. Consider this example (from

Re: std::vector move assign patch

On Tue, 25 Apr 2017, Jonathan Wakely wrote: On 24/04/17 22:10 +0200, Marc Glisse wrote: It seems that this patch had 2 consequences that may or may not have been planned. Consider this example (from PR64601) #include typedef std::vector V; void f(V,V){ V(std::move(w)).swap(v); } void g(V,V

Re: X /[ex] 4 < Y /[ex] 4

overlap with someone else's. I just have a couple more transformations of the type (X OP Y) CMP (X OP Z), but that will not affect std::vector. My first guess for improving std::vector would be around the lack of magic in new/delete, compared to malloc/free. -- Marc Glisse

Re: std::vector move assign patch

ms to turn v into a nice empty vector, while f(v,v) turns it into an invalid vector pointing at released memory. Since 2) is a nice side-effect, it may not be worth rewriting operator= in a way that improves 1) but loses 2). Anyway, just mentioning this here. -- Marc Glisse

Re: Let tree_single_nonzero_warnv_p use VRP

On Mon, 24 Apr 2017, Martin Sebor wrote: On 04/23/2017 03:38 PM, Marc Glisse wrote: Hello, this patches teaches tree_expr_nonzero_warnv_p to handle SSA_NAME using range information and known (non-)zero bits, by delegating to expr_not_equal_to which already knows how to handle all

Re: Let tree_single_nonzero_warnv_p use VRP

On Mon, 24 Apr 2017, Jakub Jelinek wrote: On Mon, Apr 24, 2017 at 09:41:01AM +0200, Richard Biener wrote: On Sun, Apr 23, 2017 at 11:38 PM, Marc Glisse <marc.gli...@inria.fr> wrote: Hello, this patches teaches tree_expr_nonzero_warnv_p to handle SSA_NAME using range information and

Re: X /[ex] 4 < Y /[ex] 4

On Mon, 24 Apr 2017, Jakub Jelinek wrote: +/* X / 4 < Y / 4 iif X < Y when the division is known to be exact. */ s/iif/iff/ ? Indeed, thanks, I've fixed it locally. -- Marc Glisse

X /[ex] 4 < Y /[ex] 4

Hello, we were missing this simplification on comparisons. Note that the testcase still does not simplify as much as one might like, we don't turn x+z

Let tree_single_nonzero_warnv_p use VRP

. 2017-04-24 Marc Glisse <marc.gli...@inria.fr> gcc/ * fold-const.c (tree_single_nonzero_warnv_p): Handle SSA_NAME. gcc/testsuite/ * gcc.dg/tree-ssa/cmpmul-1.c: New file. * gcc.dg/Wstrict-overflow-18.c: Xfail. -- Marc GlisseIndex: gcc/fold-c

Re: Deprecating arithmetic on std::atomic<void*>

ite new code that violates the standard... -- Marc Glisse

Re: [PATCH] Fix PR80275

e-optimized" } #include Making g static should work even with PIC. -- Marc Glisse

Re: [PATCH] Fix PR80281

as well, it seems possible to transform X-INT_MIN into X+INT_MIN if INT_MIN comes as (int)(-(unsigned)INT_MIN). -- Marc Glisse

Re: [C++ PATCH] PR c++/35878

ging the condition that uses it? One of the tests for flag_check_new is redundant. In C++17 mode, you test for NULL return from throwing operator new, why? This is a DR, doesn't it mean that it should apply to all modes? Or is the hope that limiting it to an experimental mode might let it pass in

Re: [PATCH 2/5][P1][tree-optimization/71437] Record more equivalences in some cases

p;(b>=0) since it just tests for the sign bit (surprisingly we seem to generate different code for the 2 versions). -- Marc Glisse

Re: PR79697: Delete calls to strdup, strndup, realloc if there is no lhs

can perform the same optimization as with malloc, wouldn't it be better to optimize: realloc(0,n) -> malloc(n) and let the malloc optimizations happen? (realloc(p,0)->free(p) is more tricky because of the return value, like malloc(0)) -- Marc Glisse

Re: [PATCH] Look through clobber stmts in uninit (PR tree-optimization/79345)

are very far from the start of the function. -- Marc Glisse

Re: [PATCH] Fix PR79547

trcspn, __builtin_object_size and __builtin_constant_p without any constraints. We have EAF_NOESCAPE that we are using for non-builtins, though it probably gets little use there. Would it make sense to use it here as well, or would that be pointless? -- Marc Glisse

Re: [RFA][PR tree-optimization/79095] [PATCH 1/4] Improve ranges for MINUS_EXPR and EXACT_DIV_EXPR V2

On Mon, 13 Feb 2017, Jeff Law wrote: On 02/13/2017 09:15 AM, Marc Glisse wrote: On Mon, 13 Feb 2017, Jeff Law wrote: On 02/12/2017 12:13 AM, Marc Glisse wrote: On Tue, 7 Feb 2017, Jeff Law wrote: * tree-vrp.c (extract_range_from_binary_expr_1): For EXACT_DIV_EXPR, if the numerator has

Re: [RFA][PR tree-optimization/79095] [PATCH 1/4] Improve ranges for MINUS_EXPR and EXACT_DIV_EXPR V2

On Mon, 13 Feb 2017, Jeff Law wrote: On 02/12/2017 12:13 AM, Marc Glisse wrote: On Tue, 7 Feb 2017, Jeff Law wrote: * tree-vrp.c (extract_range_from_binary_expr_1): For EXACT_DIV_EXPR, if the numerator has the range ~[0,0] make the resultant range ~[0,0]. If I understand correctly, for x

Re: [PATCH] Improve x % y to x VRP optimization (PR tree-optimization/79408)

On Mon, 13 Feb 2017, Jakub Jelinek wrote: On Mon, Feb 13, 2017 at 09:59:12AM +0100, Richard Biener wrote: On Sun, 12 Feb 2017, Marc Glisse wrote: On Sun, 12 Feb 2017, Marc Glisse wrote: On Tue, 7 Feb 2017, Jakub Jelinek wrote: * tree-vrp.c (simplify_div_or_mod_using_ranges

Re: [RFA][PR tree-optimization/79095] [PATCH 1/4] Improve ranges for MINUS_EXPR and EXACT_DIV_EXPR V2

to the EXACT_DIV_EXPR case (and supposedly the patch will be reverted if we get a new non-contiguous version of ranges, where union would already work). Is that it? -- Marc Glisse

Re: [PATCH] Improve x % y to x VRP optimization (PR tree-optimization/79408)

On Sun, 12 Feb 2017, Marc Glisse wrote: On Tue, 7 Feb 2017, Jakub Jelinek wrote: * tree-vrp.c (simplify_div_or_mod_using_ranges): If op1 is not constant, but SSA_NAME with a known integer range, use the minimum of that range instead of op1 to determine if modulo can

Re: [PATCH] Improve x % y to x VRP optimization (PR tree-optimization/79408)

. Would it make sense to use something like the operand_less_p helper so we would also handle an INTEGER_CST lhs? unsigned f(unsigned x){ if(x<42)return 18; return 33%x; } -- Marc Glisse

Re: gcc.css colors

(assuming I read the doc correctly)? Possibly relax things even more if it helps other customization tools? -- Marc Glisse

Re: [PATCH][RFA][PR tree-optimization/79095] Improve overflow test optimization and avoid invalid warnings

1 == 0 will get canonicalized back into x == -1. Well, it doesn't always get canonicalized since I got different code above for b==0 and for a==-1. There may be another single_use check in there. But that was probably not a good idea anyway. -- Marc Glisse

Re: [PATCH][RFA][PR tree-optimization/79095] Improve overflow test optimization and avoid invalid warnings

ous. -- Marc Glisse

Re: [PATCH][RFA][PR tree-optimization/79095] Improve overflow test optimization and avoid invalid warnings

cmove %edx, %eax while with a==-1 we have the redundant comparison leal1(%rdi), %eax cmpl$-1, %edi movl$42, %edx cmove %edx, %eax Simplifying x + 1 < x to x + 1 == 0 might not be enough to simplify your examples though I guess? -- Marc Glisse

Re: A + B CMP A -> A CMP' CST' match.pd patterns [was [PATCH] avoid calling memset et al. with excessively large sizes (PR 79095)]

to match.pd. But I agree that most transformations do not look at ranges at all. -- Marc Glisse

Re: [PATCH] PR libstdc++/79206 check string_view sizes in operator==

On Tue, 24 Jan 2017, Jonathan Wakely wrote: I've just committed this, and then noticed that we don't do the same optimization for basic_string unless the char_type is char. Note the "see also" field in that PR ;-) -- Marc Glisse

<    1   2   3   4   5   6   7   8   9   10   >