On Mon, Sep 18, 2023 at 12:09 AM Richard Biener via Gcc-patches
wrote:
>
> On Sat, Sep 16, 2023 at 7:50 AM Andrew Pinski via Gcc-patches
> wrote:
> >
> > Transforming `(a * b@[0,1]) != 0` into `((cast)b) & a != 0`
>
> that isn't strictly a simplification (one
So the xfail was there because at one point the difference
from having logical-op-non-short-circuit set to 1 or 0 made a
difference in being able to optimizing a conditional way.
This has not been true for over 10 years in this case so
instead of keeping on adding to the xfail list, removing it
is
So it turns out VN can't handle any kind of recusion for match. In this
case we have `b = a & -1` and we try to match a as being zero_one_valued_p
and VN returns b as being the value and we just go into an infinite loop at
this point.
OK? Bootstrapped and tested on x86_64-linux-gnu with no
So when VN finds a name which has a nop conversion, it says
both names are equivalent to each other and the valuaization
function for one will return the other. This normally does not
cause any issues as there is no recusive matches. But after
r14-4038-gb975c0dc3be285, there was one added. So we
`(a == CST) & a` can be either simplified to simplying `a == CST`
or 0 depending on the first bit of the CST.
This is an extension of the already pattern of `X & !X` and allows
us to remove the 2 xfails on gcc.dg/binop-notand1a.c and
gcc.dg/binop-notand4a.c.
OK? Bootstrapped and tested on
Transforming `(a * b@[0,1]) != 0` into `((cast)b) & a != 0`
will produce better code as a lot of the time b is defined
by a comparison.
Also since canonicalize `a & -zero_one` into `a * zero_one` we
start to lose information when doing comparisons against 0.
In the case of PR 110992, we lose that
On Fri, Sep 15, 2023 at 8:12 AM Qing Zhao wrote:
>
>
>
> > On Sep 15, 2023, at 3:43 AM, Xi Ruoyao wrote:
> >
> > On Thu, 2023-09-14 at 21:41 +, Qing Zhao wrote:
> CLANG already provided -fsanitize=unsigned-integer-overflow. GCC
> might need to do the same.
> >>>
> >>> NO. There is
On Thu, Sep 14, 2023 at 11:28 PM Richard Biener via Gcc-patches
wrote:
>
> On Fri, Sep 15, 2023 at 3:09 AM Andrew Pinski via Gcc-patches
> wrote:
> >
> > I noticed we sometimes lose range information in forwprop due to a few
> > match and simplify patterns optimizin
I noticed we sometimes lose range information in forwprop due to a few
match and simplify patterns optimizing away casts. So the easier way
to these cases is to add a match for zero_one_valued_p wich mathes
a cast from another zero_one_valued_p.
This also adds the case of `x & zero_one_valued_p`
On Thu, Sep 14, 2023 at 1:50 PM Qing Zhao via Gcc-patches
wrote:
>
>
>
> > On Sep 14, 2023, at 12:18 PM, Xi Ruoyao wrote:
> >
> > On Thu, 2023-09-14 at 15:57 +, Qing Zhao via Gcc-patches wrote:
> >> Currently, GCC behaves as following:
> >>
> >> /* True if overflow wraps around for the given
I had missed that integer_onep can match vector types with uniform constant of
`1`.
This means the shifter could be an scalar type and then doing a comparison
against `0`
would be an invalid transformation.
This fixes the problem by adding a check for the type of the integer_onep to
make
sure
Even though this is done via reassocation, match can support
these with a simple change to detect that the difference is just
one. This allows to optimize these earlier and even during phiopt
for an example.
This patch adds the following cases:
(a != (CST+1)) & (a > CST) -> a > (CST+1)
(a !=
While writing some match.pd code, I was trying to figure
out why I was getting an `expected ), got (` error message
while writing an if statement with an else clause. For switch
statements, the if statements cannot have an else clause so
it would be better to have a decent error message saying
On Tue, Sep 12, 2023 at 11:45 PM Richard Biener via Gcc-patches
wrote:
>
> On Tue, Sep 12, 2023 at 5:31 PM Andrew Pinski via Gcc-patches
> wrote:
> >
> > This adds a few more minmax cmp operand simplifications which were missed
> > before.
> > `MIN(
This merges the two patterns to catch
`(X % Y) < Y` and `Y > (X % Y)` into one by
using :c on the comparison operator.
It does not change any code generation nor
anything else. It is more to allow for better
maintainability of this pattern.
OK? Bootstrapped and tested on x86_64-linux-gnu.
Since matching C1 as C2 here will decrease how much other simplifications
will need to happen to get the final answer.
OK? Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* match.pd (`X <= MAX(X, Y)`):
Move before `MIN (X, C1) < C2` pattern.
---
gcc/match.pd | 15
This adds a few more minmax cmp operand simplifications which were missed
before.
`MIN(a,b) < a` -> `a > b`
`MIN(a,b) >= a` -> `a <= b`
`MAX(a,b) > a` -> `a < b`
`MAX(a,b) <= a` -> `a >= b`
OK? Bootstrapped and tested on x86_64-linux-gnu.
Note gcc.dg/pr96708-negative.c needed to updated to
This adds the missing optimizations here.
Note we don't need to match where CMP1 and CMP2 are complements of each
other as that is already handled elsewhere.
I added a new executable testcase to make sure we optimize it correctly
as I had originally messed up one of the entries for the resulting
When I added this pattern in r14-337-gc43819a9b4cd, I had missed the :c on the
cmp
part of the pattern meaning there might be some missing optimizations happening.
The testcase shows an example of the missed optmization.
Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
When I added this pattern in r14-1411-g17cca3c43e2f49, I had missed the :c on
the cmp
part of the pattern meaning there might be some missing optimizations happening.
The testcase shows an example of the missed optmization.
Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
I noticed this while working on other MINMAX optimizations. It was
hard to find a simplified testcase though because it was dependent on
the ssa name versions. Adding the `:c` to cmp allows the pattern to
be match for the case where minmax as the first operand of the comparison
rather than the
The problem here is after r6-7425-ga9fee7cdc3c62d0e51730,
the comparison to see if the transformation could be done was using the
wrong value. Instead of see if the inner was LE (for MIN and GE for MAX)
the outer value, it was comparing the inner to the value used in the comparison
which was
On Thu, Sep 7, 2023 at 10:25 PM Lehua Ding wrote:
>
> Hi,
>
> This patch adds support that tries to fold `MIN (poly, poly)` to
> a constant. Consider the following C Code:
Does it make sense to handle max also?
Thanks,
Andrew
>
> ```
> void foo2 (int* restrict a, int* restrict b, int n)
> {
>
On Tue, Sep 5, 2023 at 2:51 PM Jakub Jelinek wrote:
>
> On Tue, Sep 05, 2023 at 02:27:10PM -0700, Andrew Pinski wrote:
> > > I admit it isn't really clear to me what do you want to achieve by the
> > > above build_nonstandard_integer_type. Is it because of BOOLEAN_TYPE
> > > or perhaps
On Tue, Sep 5, 2023 at 12:31 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> Recent match.pd changes trigger ICE in build_minus_one_cst, apparently
> I forgot to handle BITINT_TYPE in these (while I've handled it in
> build_zero_cst).
>
> Will commit as obvious together with the rest of the
On Tue, Sep 5, 2023 at 12:28 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Wed, Aug 09, 2023 at 12:19:54PM -0700, Andrew Pinski via Gcc-patches wrote:
> > PR tree-optimization/110937
> > PR tree-optimization/100798
> > --- a/gcc/match.pd
> > +++ b/gcc/ma
On Tue, Sep 5, 2023 at 12:09 AM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 9/1/23 20:32, Andrew Pinski via Gcc-patches wrote:
> > This turns out to be a latent bug in ssa_name_has_boolean_range
> > where it would return true for all boolean types
On Mon, Sep 4, 2023 at 11:06 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 9/1/23 11:30, Andrew Pinski via Gcc-patches wrote:
> > So it turns out there was a simplier way of starting to
> > improve VRP to start to fix PR 110131, PR 108360, and PR 108397.
> > That wa
Adding some more simple bit_and/bit_ior patterns.
How often these show up, I have no idea.
This was tested on top of
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629174.html .
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
PR
This adds `~MAX(~X, Y)` and `~MIN(~X, Y)` patterns
that are like the `~(~a & b)` and `~(~a | b)` patterns
and allows to reduce the number of ~ by 1.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR tree-optimization/96694
gcc/ChangeLog:
* match.pd
Like the pattern already there for `(x | y) & x`,
this adds a simple pattern to optimize `(x | y) & (x & z)`
to just `x & z`.
OK? Bootstrapped and tested on x86-64-linux-gnu with no regressions.
gcc/ChangeLog:
PR tree-optimization/103536
* match.pd (`(x | y) & (x & z)`,
We currently have a pattern for handling `(C >> X) & D == 0`
but if C is 1 and D is 1, the `& 1` might have been removed.
gcc/ChangeLog:
PR tree-optimization/105832
* match.pd (`(1 >> X) != 0`): New pattern
gcc/testsuite/ChangeLog:
PR tree-optimization/105832
*
This improves rewrite_to_defined_overflow slightly if we already
have an unsigned type. The only place where this seems to show up
is ifcombine. It removes one extra statement which gets added and
then later on removed.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
Right now ssa_name_has_boolean_range compares the range to
range_true_and_false but instead we would get the nonzero bits and
compare that to 1 instead (<=u 1).
The nonzerobits comparison can be done in similar fashion.
Note I think get_nonzero_bits is redundant as the range queury will
return a
This replaces all uses of ssa_name_has_boolean_range with zero_one_valued_p
except for the one in the definition of zero_one_valued_p. This simplifies
the code in general and makes only one way of saying we have a range of [0,1].
Note this depends on the patch that adds ssa_name_has_boolean_range
Currently zero_one_valued_p uses tree_nonzero_bits which uses
the global ranges of the SSA Names. We can improve this via using
ssa_name_has_boolean_range which uses the local ranges
which are used while handling folding during VRP and other passes.
OK? Bootstrapped and tested on x86_64 with no
This allows removal of one conversion and in the case of booleans, might be
able to remove
the negate and the other conversion later on.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR tree-optimization/107137
gcc/ChangeLog:
* match.pd
This turns out to be a latent bug in ssa_name_has_boolean_range
where it would return true for all boolean types but all of the
uses of ssa_name_has_boolean_range was expecting 0/1 as the range
rather than [-1,0].
So when I fixed vector lower to do all comparisons in boolean_type
rather than still
So it turns out there was a simplier way of starting to
improve VRP to start to fix PR 110131, PR 108360, and PR 108397.
That was rewrite test_for_singularity to use range_op_handler
and Value_Range.
This patch implements that and
OK? Bootstrapped and tested on x86_64-linux-gnu with no
As requested and make easier to understand with the new ranger
code, rename the arguments op0/op1 to op1/op2.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions
gcc/ChangeLog:
* vr-values.cc (test_for_singularity): Rename
arguments op0/op1 to op1/op2.
---
On Fri, Aug 11, 2023 at 8:08 AM Andrew MacLeod via Gcc-patches
wrote:
>
>
> On 8/11/23 05:51, Richard Biener wrote:
> > On Fri, Aug 11, 2023 at 11:17 AM Andrew Pinski via Gcc-patches
> > wrote:
> >> So it turns out there was a simplier way of starting to
>
This pushes the conversion further down the chain which allows to optimize away
more
conversions in many cases.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR tree-optimization/107765
PR tree-optimization/107137
gcc/ChangeLog:
* match.pd
On Thu, Aug 31, 2023 at 5:15 AM Richard Biener via Gcc-patches
wrote:
>
> On Thu, 31 Aug 2023, Filip Kastl wrote:
>
> > > The most obvious places would be right after SSA construction and before
> > > RTL expansion.
> > > Can you provide measurements for those positions?
> >
> > The algorithm
This patch adds the following match patterns to optimize these:
/* (a != b) ? (a - b) : 0 -> (a - b) */
/* (a != b) ? (a ^ b) : 0 -> (a ^ b) */
/* (a != b) ? (a & b) : a -> (a & b) */
/* (a != b) ? (a | b) : a -> (a | b) */
/* (a != b) ? min(a,b) : a -> min(a,b) */
/* (a != b) ? max(a,b) : a
This simple patch extends the min_value/max_value match to vector integer types.
Using uniform_integer_cst_p makes this easy.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
The testcases pr110915-*.c are the same as pr88784-*.c except using vector
types instead.
PR
This moves the match pattern `(x | y) & (~x ^ y)` over to use
bitwise_inverted_equal_p.
This now also allows to optmize comparisons and also catches the missed `(~x |
y) & (x ^ y)`
transformation into `~x & y`.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
This adds `--param logical-op-non-short-circuit=1` to the tescase
so it becomes a target indepdendent testcase now.
I filed PR 111217 as the variant of the testcase which fails indepdendently
of the param.
Committed as obvious after testing to make sure it passes on powerpc now.
After r14-2885-gb9237226fdc938, this pattern becomes
redundant as we match it using bitwise_inverted_equal_p.
There is already a testcase (gcc.dg/nand.c) for this pattern
and it still passes after the removal.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
This adds a simple case to remove an outer condition if the two inner
condtionals are the same and lead the same location.
This can show up due to jump threading or inlining or someone wrote code
like this.
ifcombine-1.c shows the simple case where this is supposed to solve.
Even though PRE can
This adds dump on the full result of the match-and-simplify
for phiopt and specifically to know if we are rejecting something
due to being in early phi-opt.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* tree-ssa-phiopt.cc (gimple_simplify_phiopt):
Somehow when I was testing the new testcase, it was working but
when I re-ran the full testsuite it was not. Anyways the issue
was just a simple space before the `}` for dg-options directive.
Committed as obvious.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/phi-opt-34.c: Fix dg-options
On Thu, Aug 24, 2023 at 11:47 PM Richard Biener via Gcc-patches
wrote:
>
> On Thu, Aug 24, 2023 at 9:16 PM Andrew Pinski via Gcc-patches
> wrote:
> >
> > Now that MIN/MAX can sometimes be transformed into BIT_AND/BIT_IOR,
> > we should allow BIT_AND and BIT_IOR in th
In PR 106677, I noticed that on the trunk we were producing:
```
_25 = SR.116_117 == 0;
_27 = (unsigned char) _25;
_32 = _27 | SR.116_117;
```
>From `SR.115_117 != 0 ? SR.115_117 : 1`
Rather than:
```
_119 = MAX_EXPR <1, SR.115_117>;
```
Or (rather)
```
_119 = SR.115_117 | 1;
```
Due to
On Fri, Aug 25, 2023 at 11:11 AM Andrew Pinski wrote:
>
> On Thu, Aug 24, 2023 at 11:39 PM Richard Biener via Gcc-patches
> wrote:
> >
> > On Thu, Aug 24, 2023 at 9:16 PM Andrew Pinski via Gcc-patches
> > wrote:
> > >
> > > In PR 106677,
On Thu, Aug 24, 2023 at 11:39 PM Richard Biener via Gcc-patches
wrote:
>
> On Thu, Aug 24, 2023 at 9:16 PM Andrew Pinski via Gcc-patches
> wrote:
> >
> > In PR 106677, I noticed that on the trunk we were producing:
> > ```
> > _25 = SR.116_117 == 0;
> >
This moves the pattern `(X & ~Y) | (~X & Y)` to use bitwise_inverted_equal_p
so we can simplify earlier the case where X and Y are defined by comparisons.
We were able to optimize to (!X)^(!Y) in the end due to the pattern added in
r14-3110-g7fb65f102851248bafa0815 and the older pattern
On Thu, Aug 24, 2023 at 11:37 PM Richard Biener via Gcc-patches
wrote:
>
> On Thu, Aug 24, 2023 at 9:16 PM Andrew Pinski via Gcc-patches
> wrote:
> >
> > Even though this is handled by other code inside both VRP and CCP,
> > sometimes we want to optimize
Now that MIN/MAX can sometimes be transformed into BIT_AND/BIT_IOR,
we should allow BIT_AND and BIT_IOR in the early phiopt.
Also we produce BIT_AND/BIT_IOR for things like `bool0 ? bool1 : 0`
which seems like a good thing to allow early on too.
OK? Bootstrapped and tested on x86_64-linux-gnu
In PR 106677, I noticed that on the trunk we were producing:
```
_25 = SR.116_117 == 0;
_27 = (unsigned char) _25;
_32 = _27 | SR.116_117;
```
>From `SR.115_117 != 0 ? SR.115_117 : 1`
Rather than:
```
_119 = MAX_EXPR <1, SR.115_117>;
```
Or (rather)
```
_119 = SR.115_117 | 1;
```
Due to
Even though this is handled by other code inside both VRP and CCP,
sometimes we want to optimize this outside of VRP and CCP.
An example is given in PR 106677 where phiopt will happen
after VRP (which removes a cast for a comparison) and then
phiopt will optimize the phi to be `a | 1` which can
For 1bit types, negate is either undefined or don't change the value.
In either cases we want to remove them.
This patch adds a match pattern to do that.
Also converting to a 1bit type we can remove the negate just like we already do
for `&1` so this patch adds that too.
OK? Bootstrapped and
The patterns that were added in r13-4620-g4d9db4bdd458, missed that
(a > b) and (a <= b) are not inverse of each other for floating point
comparisons (if NaNs are supported). Even though there was a check for
intergal types, it was only for the result of the cond rather for the
type of what is
On Mon, Aug 21, 2023 at 8:25 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> On Wed, Aug 09, 2023 at 08:14:14PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > Jakub Jelinek (12):
> > expr: Small optimization [PR102989]
> > lto-streamer-in: Adjust assert [PR102989]
> > phiopt: Fix
On Mon, Aug 21, 2023 at 10:42 PM Lehua Ding wrote:
>
> Hi,
>
> This patch add conditional unary neg/abs/not autovec patterns to RISC-V
> backend.
> Consider this C code:
>
> void
> test_3 (float *__restrict a, float *__restrict b, int *__restrict pred, int n)
> {
> for (int i = 0; i < n; i +=
On Fri, Aug 11, 2023 at 8:08 AM Andrew MacLeod via Gcc-patches
wrote:
>
>
> On 8/11/23 05:51, Richard Biener wrote:
> > On Fri, Aug 11, 2023 at 11:17 AM Andrew Pinski via Gcc-patches
> > wrote:
> >> So it turns out there was a simplier way of starting to
>
Like convert we can sink view_convert into vec_cond but
we can only do it if the element types are nop_conversions.
This is to allow conversion between signed and unsigned types only.
Rather than between integer and float types which mess up the vec_cond
so that isel does not understand `a?-1:0`
Convert be sinked into a vec_cond if both sides
fold. Unlike other unary operations, we need to check that we still can handle
this vec_cond's first operand is the same as the new truth type.
I tried a few different versions of this patch:
view_convert to the new truth_type but that does not work
When I added `cond_one_cmpl` (and the corresponding IFN) I had noticed cond_neg
standard named pattern was not documented and this adds the documentation for
all 4 named patterns now.
OK? Tested by building the manual.
gcc/ChangeLog:
* doc/md.texi (Standard patterns): Document cond_neg,
Convert be sinked into a vec_cond if both sides
fold. Unlike other unary operations, we need to check that we still can handle
this vec_cond's first operand is the same as the new truth type.
I tried a few different versions of this patch:
view_convert to the new truth_type but that does not work
On Mon, Aug 14, 2023 at 2:54 PM Andrew Pinski wrote:
>
> On Mon, Aug 14, 2023 at 2:37 PM Richard Sandiford via Gcc-patches
> wrote:
> >
> > Andrew Pinski via Gcc-patches writes:
> > > Like the support conditional neg (r12-4470-g20dcda98ed376cb61c74b2c71),
&g
On Wed, Aug 16, 2023 at 4:15 PM Patrick O'Neill wrote:
>
> This adds new regression tests to ensure half-register rotations are
> correctly optimized into rori instructions.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/zbb-rol-ror-04.c: Add half-register rotation
> cases.
>
On Wed, Aug 16, 2023 at 3:36 PM David Edelsohn via Gcc-patches
wrote:
>
> Was the dependency added to the dependencies in contrib/gcc_update?
> Otherwise the timestamp can get out of sync in a Git checkout.
I checked in https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627667.html
which just
This adds libstdc++-v3/include/bits/version.h so it has the correct timestamp.
Committed as obvious after running contrib/gcc_update --touch
contrib/ChangeLog:
* gcc_update: Add libstdc++-v3/include/bits/version.h.
---
contrib/gcc_update | 1 +
1 file changed, 1 insertion(+)
diff
On Mon, Aug 14, 2023 at 2:37 PM Richard Sandiford via Gcc-patches
wrote:
>
> Andrew Pinski via Gcc-patches writes:
> > Like the support conditional neg (r12-4470-g20dcda98ed376cb61c74b2c71),
> > this just adds conditional not too.
> > Also we should be able t
On Sun, Aug 13, 2023 at 12:20 PM Eddy Young wrote:
>
> This patch changes the type of `x_spill_indirect_levels` member of
> `struct target reload` from `bool` to `unsigned char`.
>
> Without this change, the build of esp-open-sdk fails with GCC 11 and
> above.
This was done back in d57c99458933
On Sun, Aug 13, 2023 at 12:05 PM Eddy Young Tie Yang
wrote:
>
> From d57ac4f9a095a2f616863efd524ac2d87276becb Mon Sep 17 00:00:00 2001
> From: Eddy Young
> Date: Sun, 13 Aug 2023 19:59:12 +0100
> Subject: [PATCH] gcc/reload.h: Change type of x_spill_indirect_levels
>
> ---
> ChangeLog| 5
Like the support conditional neg (r12-4470-g20dcda98ed376cb61c74b2c71),
this just adds conditional not too.
Also we should be able to turn `(a ? -1 : 0) ^ b` into a conditional
not.
OK? Bootstrapped and tested on x86_64-linux-gnu and aarch64-linux-gnu.
gcc/ChangeLog:
* internal-fn.def
So it turns out there was a simplier way of starting to
improve VRP to start to fix PR 110131, PR 108360, and PR 108397.
That was rewrite test_for_singularity to use range_op_handler
and Value_Range.
This patch implements that and
OK? Bootstrapped and tested on x86_64-linux-gnu with no
So with my next VRP patch, VRP causes:
```
# c$_M_value_18 = PHI <-1(3), 0(2), 1(4)>
_11 = (unsigned int) c$_M_value_18;
_16 = _11 <= 1;
```
To be changed to:
```
# c$_M_value_18 = PHI <-1(3), 0(2), 1(4)>
_11 = (unsigned int) c$_M_value_18;
_16 = _11 != 4294967295;
```
So let's add
On Thu, Aug 10, 2023 at 12:08 PM Andrew Pinski wrote:
>
> On Thu, Aug 10, 2023 at 12:18 AM Richard Biener via Gcc-patches
> wrote:
> >
> > On Wed, Aug 9, 2023 at 6:16 PM Andrew Pinski via Gcc-patches
> > wrote:
> > >
> > > If `A` has a
This was an oversight on my part forgetting that
cmp will might have a different true value than all ones
but will have a value of 1 in most cases.
This means if we have `(f < 0) | !(f < 0)` we would
optimize this to -1 rather than just 1.
This is version 2 of the patch.
Decided to go down a
On Thu, Aug 10, 2023 at 12:18 AM Richard Biener via Gcc-patches
wrote:
>
> On Wed, Aug 9, 2023 at 6:16 PM Andrew Pinski via Gcc-patches
> wrote:
> >
> > If `A` has a range of `[0,0][100,INF]` and the comparison
> > of `A < 50`. This should b
On Thu, Aug 10, 2023 at 12:32 AM Richard Biener via Gcc-patches
wrote:
>
> On Thu, Aug 10, 2023 at 2:21 AM Andrew Pinski via Gcc-patches
> wrote:
> >
> > This was an oversight on my part not realizing that
> > comparisons in generic can have a non-boolean type.
> &
On Thu, Aug 10, 2023 at 6:39 AM Christophe Lyon via Gcc-patches
wrote:
>
> Hi Andrew,
>
>
> On Wed, 9 Aug 2023 at 21:20, Andrew Pinski via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
> > This adds a simple match pattern for this case.
> > I noticed i
On Thu, Aug 10, 2023 at 12:13 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Thu, Aug 10, 2023 at 06:55:05AM +, Richard Biener wrote:
> > On Wed, 9 Aug 2023, Joseph Myers wrote:
> >
> > > On Wed, 9 Aug 2023, Jakub Jelinek via Gcc-patches wrote:
> > >
> > > > - _Complex _BitInt(N) isn't
This was an oversight on my part not realizing that
comparisons in generic can have a non-boolean type.
This means if we have `(f < 0) | !(f < 0)` we would
optimize this to -1 rather than just 1.
This patch just adds the check for the type of the comparisons
to be boolean type to keep the
On Wed, Aug 9, 2023 at 1:01 PM Jakub Jelinek wrote:
>
> On Wed, Aug 09, 2023 at 11:27:48AM -0700, Andrew Pinski wrote:
> > Maybe it is better to punt for VOPS after the call to
> > single_non_singleton_phi_for_edges since none of functions called
> > afterwards support VOPs.
> > That is something
This adds a simple match pattern for this case.
I noticed it a couple of different places.
One while I was looking at code generation of a parser and
also while I was looking at locations where bitwise_inverted_equal_p
should be used more.
Committed as approved after bootstrapped and tested on
On Wed, Aug 9, 2023 at 11:17 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> I've ran into ICE on gcc.dg/torture/bitint-42.c with -O1 or -Os
> when enabling expensive tests, and unfortunately I can't reproduce without
> _BitInt. The IL before phiopt3 has:
>[local count: 203190070]:
> #
If `A` has a range of `[0,0][100,INF]` and the comparison
of `A < 50`. This should be optimized to `A <= 0` (which then
will be optimized to just `A == 0`).
This patch implement this via a new function which sees if
the constant of a comparison is in the middle of 2 range pairs
and change the
On Tue, Aug 8, 2023 at 4:17 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 8/8/23 10:38, Alexander Monakov wrote:
> >
> > On Tue, 8 Aug 2023, Jeff Law wrote:
> >
> >> That was my thinking at one time. Then we started looking at the distros
> >> and
> >> found enough crc implementations in there
On Tue, Aug 8, 2023 at 12:44 AM Richard Biener via Gcc-patches
wrote:
>
> On Tue, Aug 8, 2023 at 2:55 AM Andrew Pinski via Gcc-patches
> wrote:
> >
> > This adds a simple match pattern for this case.
> > I noticed it a couple of different places.
> > One while
This adds a simple match pattern for this case.
I noticed it a couple of different places.
One while I was looking at code generation of a parser and
also while I was looking at locations where bitwise_inverted_equal_p
should be used more.
OK? Bootstrapped and tested on x86_64-linux-gnu with no
This patch fixes the oldish (2006) bug where VRP was not
optimizing the comparison for assignments while handling
them for GIMPLE_COND only.
It just happens to also solves PR 103281 due to allowing
to optimize `c < 1` to `c == 0` and then we get
`(c == 0) == c` (which was handled by
I noticed while looking into some code generation of bitmap_single_bit_set_p,
that sometimes:
```
if (uns > 1)
return 0;
return uns == 1;
```
Would not optimize down to just:
```
return uns == 1;
```
In this case, VRP likes to change `a == 1` into `(bool)a` if
a has a range of [0,1] due
Since we already had the infrastructure to optimize
`(x == 0) && (x > y)` to false for integer types,
this extends the same to pointer types as indirectly
requested by PR 96695.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
PR
On Thu, Aug 3, 2023 at 10:31 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 8/3/23 17:38, Vineet Gupta wrote:
>
> >> ;-) Actually if you wanted to poke at zicond, the most interesting
> >> unexplored area I've come across is the COND_EXPR handling in gimple.
> >> When we expand a COND_EXPR into
On Thu, Aug 3, 2023 at 12:38 PM Mariam Harutyunyan via Gcc-patches
wrote:
>
> This patch adds CRC support for the RISC-V architecture. It adds internal
> functions and built-ins specifically designed to handle CRC computations
> efficiently.
>
> If the target is ZBC, the clmul instruction is used
This changes gimple_bitwise_inverted_equal_p to use a 2 different match patterns
to try to match bit_not wrapped with a possible nop_convert and a comparison
also wrapped with a possible nop_convert. This is to avoid being recursive.
OK? Bootstrapped and tested on x86_64-linux-gnu with no
On Thu, Aug 3, 2023 at 4:58 AM Mikael Morin wrote:
>
> Hello,
>
> Le 31/07/2023 à 19:07, Andrew Pinski via Gcc-patches a écrit :
> > diff --git a/gcc/generic-match-head.cc b/gcc/generic-match-head.cc
> > index a71c0727b0b..ddaf22f2179 100644
> > --- a/gcc/gener
1 - 100 of 549 matches
Mail list logo
