On Sun, May 28, 2023 at 8:53 PM Jiufu Guo via Gcc-patches
wrote:
>
> Hi,
>
> Previously, I was investigating some struct parameters and returns related
> PRs 69143/65421/108073.
>
> Investigating the issues case by case, and drafting patches for each of
> them one by one. This would help us to enh
After r14-1014-gc5df248509b489364c573e8, GCC started to emit
directly a zero_extract for `(t1&0x8)!=0`. This introduced
a small regression where ifcvt would not do the ifconversion
as there is now a paradoxical subreg in the dest which
was being rejected. Since paradoxical subreg set the whole
regi
On Wed, May 31, 2023 at 12:29 AM Richard Biener via Gcc-patches
wrote:
>
> On Wed, May 31, 2023 at 6:34 AM Andrew Pinski via Gcc-patches
> wrote:
> >
> > After r14-1014-gc5df248509b489364c573e8, GCC started to emit
> > directly a zero_extract for `(t1&0x8)!=
On Thu, Jun 1, 2023 at 7:36 AM Jeff Law wrote:
>
>
>
> On 5/31/23 15:22, Andrew Pinski wrote:
> > On Wed, May 31, 2023 at 12:29 AM Richard Biener via Gcc-patches
> > wrote:
> >>
> >> On Wed, May 31, 2023 at 6:34 AM Andrew Pinski via Gcc-patch
The problem here is DSE was not taking into account the address space
which meant if you had two addresses say `fs:0` and `gs:0` (on x86_64),
DSE would think they were the same and remove the first store.
This fixes that issue by adding a check for the address space too.
OK? Bootstrapped and teste
On Sat, Jun 3, 2023 at 3:53 PM Takayuki 'January June' Suwa via
Gcc-patches wrote:
>
> This patch optimizes both the boolean evaluation of and the branching of
> EQ/NE against INT_MIN (-2147483648), by taking advantage of the specifi-
> cation the ABS machine instruction on Xtensa returns INT_MIN
On sh target, there is a MULTILIB_DIRNAMES (or is it MULTILIB_OPTIONS) named m2,
this conflicts with the langauge m2. So when you do a `make clean`, it will
remove
the m2 directory and then a build will fail. Now since r0-78222-gfa9585134f6f58,
the multilib directories are no longer created in the
On Sun, Jun 4, 2023 at 10:24 PM Richard Biener via Gcc-patches
wrote:
>
>
>
> > Am 05.06.2023 um 06:42 schrieb Andrew Pinski via Gcc-patches
> > :
> >
> > On sh target, there is a MULTILIB_DIRNAMES (or is it MULTILIB_OPTIONS)
> > named m2,
> > thi
After expanding directly to rtl instead of
creating a tree, we could end up with
a const_int which is not ready to be handled
by extract_bit_field.
So need to the constant folding here instead.
OK? bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR middle-end/110117
gcc/
In r14-1534-g908e5ab5c11c, I forgot you could turn off CCP or
turn off the bit tracking part of CCP so we would lose out
what TER was able to do before hand. This moves around the
TER code so that it is used instead of just the nonzerobits.
It also makes it easier to remove the TER part of the code
On Mon, Jun 5, 2023 at 9:34 PM liuhongt via Gcc-patches
wrote:
>
> Since mask < 0 will be always false when -funsigned-char, but
> vpblendvb needs to check the most significant bit.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk and backport to GCC12/GCC13 release bra
On Mon, Jun 5, 2023 at 9:34 PM liuhongt via Gcc-patches
wrote:
>
> r14-1145 fold the intrinsics into gimple ABS_EXPR which has UB for
> TYPE_MIN, but PABSB will store unsigned result into dst. The patch
> uses ABSU_EXPR + VCE instead of ABS_EXPR.
>
> Also don't fold _mm_abs_{pi8,pi16,pi32} w/o TAR
I noticed while looking at some code generation issue, that forwprop
was not handling `-a == 0` for unsigned types and I was confused why
it was not.
r6-1814-g66e1cacf608045 removed these from fold because they
were supposed to be already handled by the match.pd patterns
but it was missed that the
On sh target, there is a MULTILIB_DIRNAMES (or is it MULTILIB_OPTIONS) named m2,
this conflicts with the langauge m2. So when you do a `make clean`, it will
remove
the m2 directory and then a build will fail. Now since r0-78222-gfa9585134f6f58,
the multilib directories are no longer created in the
While working on `bool0 ? bool1 : bool2` I noticed that
zero_one_valued_p does not match on the constant zero
as in that case tree_nonzero_bits will return 0 and
that is different from 1.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* match.pd (zero
This adds a match pattern that are for boolean values
that optimizes `a ? onezero : 0` to `a & onezero` and
`a ? 1 : onezero` to `a | onezero`.
This was reported a few times and I thought I would finally
add the match pattern for this.
This hits a few times in GCC itself too.
Notes on the testca
On Mon, Jun 5, 2023 at 9:52 PM Dimitar Dimitrov wrote:
>
> During libgcc configure stage for riscv32-none-elf, when
> "--enable-checking=yes,rtl" has been activated, the following error
> is observed:
>
> configure:3814:
> /home/dinux/projects/pru/local-workspace/riscv32-gcc-build/./gcc/xgcc
>
On Sun, Jun 4, 2023 at 10:43 AM Jeff Law via Gcc-patches
wrote:
>
> With Vlad's recent LRA fix to the elimination code, the H8 can be
> converted to LRA.
Could you update the h8300 entry on https://gcc.gnu.org/backends.html
for this change?
Thanks,
Andrew
>
> This patch has two changes of note.
The patterns match more than just `a & 1` so change the comment
for these two patterns to say that.
Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
gcc/ChangeLog:
* match.pd: Fix comment for the
`(zero_one ==/!= 0) ? y : z y` patterns.
---
gcc/match.pd | 4 ++--
This allows unsigned types if the inner type where the negation is
located has greater than or equal to precision than the outer type.
branchless-cond.c needs to be updated since now we change it to
use a multiply rather than still having (-a)&c in there.
OK? Bootstrapped and tested on x86_64-lin
Since there is a pattern to convert `(-zero_one) & z` into `zero_one * z`
already,
it is better if we don't do a secondary transformation. This reduces the extra
statements produced by match-and-simplify on the gimple level too.
gcc/ChangeLog:
* match.pd (`zero_one ==/!= 0) ? y : z y`):
This adds plus to the op list of `(zero_one == 0) ? y : z y` patterns
which currently has bit_ior and bit_xor.
This shows up now in GCC after the boolization work that Uroš has been doing.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR tree-optimization/97711
On Wed, Jun 7, 2023 at 3:57 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 6/7/23 15:32, Andrew Pinski via Gcc-patches wrote:
> > Since there is a pattern to convert `(-zero_one) & z` into `zero_one * z`
> > already,
> > it is better if we don't do a sec
On Wed, Jun 7, 2023 at 4:11 PM Jeff Law wrote:
>
>
>
> On 6/7/23 17:05, Andrew Pinski wrote:
> > On Wed, Jun 7, 2023 at 3:57 PM Jeff Law via Gcc-patches
> > wrote:
> >>
> >>
> >>
> >> On 6/7/23 15:32, Andrew Pinski via Gcc-patches wrote
So for the attached testcase, we assumed that zero_one_valued_p would
be the value [0,1] but currently zero_one_valued_p matches also
signed 1 bit integers.
This changes that not to match that and fixes the 2 new testcases at
all optimization levels.
OK? Bootstrapped and tested on x86_64-linux-gnu
So for the attached testcase, we assumed that zero_one_valued_p would
be the value [0,1] but currently zero_one_valued_p matches also
signed 1 bit integers.
This changes that not to match that and fixes the 2 new testcases at
all optimization levels.
OK for GCC 13? Bootstrapped and tested on x86_6
Match will query ranger via tree_nonzero_bits/get_nonzero_bits for 2 and 3rd
operand of the COND_EXPR and phiopt tries to do create the COND_EXPR even if we
moving
one statement. That one statement could have some flow sensitive information on
it
based on the condition that is for the COND_EXPR b
Since the combining of sin/cos into cexpi is depedent
on the target, this adds another testcase which had failed (earlier in
evpr rather than vrp2) that will fail on all targets rather than
ones which have sincos or C99 math functions.
Committed as obvious after a quick test.
gcc/testsuite/Change
This fixes part of PR 110293, for the outer comparison case
being `!=` or `==`. In turn PR 110539 is able to be optimized
again as the if statement for `(a&1) == ((a & 1) != 0)` gets optimized
to `false` early enough to allow FRE/DOM to do a CSE for memory store/load.
OK? Bootstrapped and tested
On Fri, Jul 14, 2023 at 11:56 AM Roger Sayle wrote:
>
>
>
> This patch fixes the bootstrap failure I'm seeing using gcc 4.8.5 as
>
> the host compiler. Ok for mainline? [I might be missing something]
I think adding const here makes this well defined C++20 too.
See http://cplusplus.github.io/LWG
On Thu, Jul 13, 2023 at 2:54 AM Richard Biener via Gcc-patches
wrote:
>
> The following makes sure that FP x > y ? x : y style max/min operations
> are if-converted at the GIMPLE level. While we can neither match
> it to MAX_EXPR nor .FMAX as both have different semantics with IEEE
> than the ter
I had messed up the case where the outer operator is `==`.
The check for the resulting should have been `==` and not `!=`.
This patch fixes that and adds a full runtime testcase now for
all cases to make sure it works.
OK? Bootstrapped and tested on x86-64-linux-gnu with no regressions.
gcc/Chang
Match will query ranger via tree_nonzero_bits/get_nonzero_bits for 2 and 3rd
operand of the COND_EXPR and phiopt tries to do create the COND_EXPR even if we
moving
one statement. That one statement could have some flow sensitive information on
it
based on the condition that is for the COND_EXPR b
This adds flow_sensitive_info_storage and uses it in
maybe_fold_comparisons_from_match_pd as mentioned in
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621817.html .
Since using it in maybe_fold_comparisons_from_match_pd was easy
and allowed me to test the storage earlier, I did it.
This als
On Wed, Jul 12, 2023 at 6:37 AM Richard Biener via Gcc-patches
wrote:
>
> The PRs ask for optimizing of
>
> _1 = BIT_FIELD_REF ;
> result_4 = BIT_INSERT_EXPR ;
>
> to a vector permutation. The following implements this as
> match.pd pattern, improving code generation on x86_64.
This is more
On Sat, Jul 15, 2023 at 10:31 AM Andrew Pinski wrote:
>
> On Wed, Jul 12, 2023 at 6:37 AM Richard Biener via Gcc-patches
> wrote:
> >
> > The PRs ask for optimizing of
> >
> > _1 = BIT_FIELD_REF ;
> > result_4 = BIT_INSERT_EXPR ;
> >
> > to a vector permutation. The following implements this
Committed as obvious after making sure the documentation still builds.
gcc/ChangeLog:
* doc/contrib.texi: Update my entry.
---
gcc/doc/contrib.texi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/doc/contrib.texi b/gcc/doc/contrib.texi
index fa551c5f900..d7b73e1
This adds the boolean version of some of the simplifications
that were added with r8-4395-ge268a77b59cb78.
That are the following:
(a | b) & (a == b) --> a & b
a | (a == b) --> a | (b ^ 1)
(a & b) | (a == b) --> a == b
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gc
On Mon, Jul 17, 2023 at 12:21 AM Tamar Christina via Gcc-patches
wrote:
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Monday, July 17, 2023 7:19 AM
> > To: Roger Sayle
> > Cc: gcc-patches@gcc.gnu.org; Tamar Christina
> > Subject: Re: [PATCH] Fix bootstrap failure (with g++
On Sun, Jul 16, 2023 at 11:49 PM Christoph Müllner
wrote:
>
> On Fri, Jul 14, 2023 at 12:28 PM Andreas Schwab wrote:
> >
> > Why didn't you test that?
>
> Thanks for reporting, and sorry for introducing this warning.
>
> I test all patches before sending them.
> In the case of RISC-V backend patc
On Mon, Jul 17, 2023 at 2:30 AM Richard Biener wrote:
>
> On Fri, 14 Jul 2023, Andrew Pinski wrote:
>
> > On Thu, Jul 13, 2023 at 2:54?AM Richard Biener via Gcc-patches
> > wrote:
> > >
> > > The following makes sure that FP x > y ? x : y style max/min operations
> > > are if-converted at the GIM
So I had missed/forgot that EQ_EXPR could have an non boolean
type for generic when I implemented r14-2556-g0407ae8a7732d9.
This patch adds check for one bit precision intergal type
which fixes the problem.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR tree-optim
On Wed, Jul 19, 2023 at 12:16 AM Richard Biener via Gcc-patches
wrote:
>
> On Wed, Jul 19, 2023 at 3:53 AM Andrew Pinski via Gcc-patches
> wrote:
> >
> > So I had missed/forgot that EQ_EXPR could have an non boolean
> > type for generic when I implemented r14-2556-g040
Since we have statistics_counter_event now, combine should use that
instead of it is own custom printing of statistics.
The only thing that is not done any more after this patch is printing
out the total stats for the whole TU.
Note you need to use -fdump-rtl-combine-stats to get the stats in the
This adds a simple match pattern to simplify
`max,a>` to `max`. Reassociation handles
this already (r0-77700-ge969dbde29bfd396259357) but
seems like we should be able to handle this even before
reassociation.
This fixes part of PR tree-optimization/80574 but more
work is needed fix it the rest of
So the problem here is EXPAND_INTER_MACRO_16 expands to nothing if 16 byte FP
does not
exist but we still add a comma after it and that causes a build failure.
The same is true for EXPAND_INTER_MACRO_10 too.
Committed as obvious after a bootstrap and test on x86_64-linux-gnu and
aarch64-linux-gn
On Fri, Jul 21, 2023 at 8:09 AM Drew Ross via Gcc-patches
wrote:
>
> Simplifies (x << c) >> c where x is a signed integral type of
> width >= int and c = precision(type) - 1 into -(x & 1). Tested successfully
> on x86_64 and x86 targets.
Thinking about this some more, I think this should be handl
On Fri, Jul 21, 2023 at 5:13 AM Matthew Malcomson via Gcc-patches
wrote:
>
> On some AArch64 bootstrapped builds, we were getting a flaky test
> because the floating point operations in `get_time` were being fused
> with the floating point operations in `timevar_accumulate`.
>
> This meant that th
On Tue, Aug 17, 2021 at 1:43 AM Sebastian Huber
wrote:
>
> abort() is used in gcc_assert() and gcc_unreachable() which is used by target
> libraries such as libgcov.a. This patch changes the abort() definition under
> certain conditions. If inhibit_libc is defined and abort is not already
> defi
The problem is after r14-2587-gd8105b10fff951, the definition of
extended_count now takes a bool as its last argument but we only
have a declaration for the version which takes an int as the last
argument. This fixes the problem by changing the declaration to be
a bool too.
Committed as obvious af
This adds a special case of the `(a&~b) | b` pattern where
`b` and `~b` are comparisons.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
PR tree-optimization/100864
* match.pd ((~x & y) | x -> x | y): Add comparison variant.
gcc/testsuite/Chan
The problem -fasynchronous-unwind-tables is on by default for aarch64
We need turn it off for crt*.o because it would make __EH_FRAME_BEGIN__ point
to .eh_frame data from crtbeginT.o instead of the user-defined object
during static linking.
This turns it off.
OK? Bootstrapped and tested on aarch6
The problem -fasynchronous-unwind-tables is on by default for riscv linux
We need turn it off for crt*.o because it would make __EH_FRAME_BEGIN__ point
to .eh_frame data from crtbeginT.o instead of the user-defined object
during static linking.
This turns it off.
OK?
libgcc/ChangeLog:
*
In this case we are not removing convert to a bigger size
back to the same size (or smaller) if signedness does not
match.
For an example:
```
signed char _1;
...
_1 = *a_4(D);
b_5 = (short unsigned int) _1;
_2 = (unsigned char) b_5;
```
The inner cast is not needed and can be removed but w
On Tue, Jul 25, 2023 at 12:45 PM Jakub Jelinek via Gcc-patches
wrote:
>
> On Tue, Jul 25, 2023 at 03:42:21PM -0400, David Edelsohn via Gcc-patches
> wrote:
> > Hi, Drew
> >
> > Thanks for addressing this missed optimization.
> >
> > The testcase includes an incorrect assumption: signed char, whic
So the problem here is that plain char can either be signed
or unsigned depending on the target (powerpc and aarch64 are
unsigned while most other targets are signed). So the testcase
gcc.c-torture/execute/pr109986.c was assuming plain char was signed
char which is wrong so it is better to just cha
On Tue, Jul 25, 2023 at 1:54 PM Andrew Pinski wrote:
>
> On Tue, Jul 25, 2023 at 12:45 PM Jakub Jelinek via Gcc-patches
> wrote:
> >
> > On Tue, Jul 25, 2023 at 03:42:21PM -0400, David Edelsohn via Gcc-patches
> > wrote:
> > > Hi, Drew
> > >
> > > Thanks for addressing this missed optimization.
On Sun, Jul 23, 2023 at 1:39 AM Richard Biener via Gcc-patches
wrote:
>
>
>
> > Am 23.07.2023 um 01:27 schrieb Andrew Pinski via Gcc-patches
> > :
> >
> > This adds a special case of the `(a&~b) | b` pattern where
> > `b` and `~b` are comparisons.
&g
On Thu, Jul 27, 2023 at 11:38 PM Jan Hubicka via Gcc-patches
wrote:
>
> Hi,
> while looking on profile misupdate on hmmer I noticed that loop splitting
> pass is not
> able to handle the loop it has as an example it should apply on:
>
>One transformation of loops like:
>
>for (i = 0; i <
This is a new version of the patch.
Instead of doing the matching of inversion comparison directly inside
match, creating a new function (bitwise_not_equal_p) to do it.
It is very similar to bitwise_equal_p that was added in
r14-2751-g2a3556376c69a1fb
but instead it says `expr1 == ~expr2`. A follo
I noticed that there are patterns that optimize
`(X CMP1 CST1) AND/IOR (X CMP2 CST2)` and we can easily extend
them to support the `(X CMP1 Y) AND/IOR (X CMP2 Y)` by saying they
compare equal. This allows for this kind of optimization for integral
and pointer types (which have the same semantics).
Even though these are done by combine_comparisons, we can add them to match
to allow simplifcations during match rather than just during reassoc/ifcombine.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
PR tree-optimization/106164
* match.pd (
This is a new version of the patch.
Instead of doing the matching of inversion comparison directly inside
match, creating a new function (bitwise_inverted_equal_p) to do it.
It is very similar to bitwise_equal_p that was added in
r14-2751-g2a3556376c69a1fb
but instead it says `expr1 == ~expr2`. A
On Mon, Jul 31, 2023 at 3:53 AM Richard Biener via Gcc-patches
wrote:
>
> On Mon, Jul 31, 2023 at 7:35 AM Andrew Pinski via Gcc-patches
> wrote:
> >
> > Even though these are done by combine_comparisons, we can add them to match
> > to allow simplifcations during ma
This is a simple patch to move these 2 patterns over to use
bitwise_inverted_equal_p. It also allows us to remove 2 other patterns
which were used on comparisons as they are now handled by
the original pattern.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
This slighly improves bitwise_inverted_equal_p
for comparisons. Instead of just comparing the
comparisons operands also valueize them.
This will allow ccp and others to match the 2 comparisons
without an extra pass happening.
OK? Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
In some cases (usually dealing with bools only), there could be some statements
left behind which are considered trivial dead.
An example is:
```
bool f(bool a, bool b)
{
if (!a && !b)
return 0;
if (!a && b)
return 0;
if (a && !b)
return 0;
return 1;
}
```
Wh
In this case we are not removing convert to a bigger size
back to the same size (or smaller) if signedness does not
match.
For an example:
```
signed char _1;
...
_1 = *a_4(D);
b_5 = (short unsigned int) _1;
_2 = (unsigned char) b_5;
```
The inner cast is not needed and can be removed but w
On Thu, Jun 30, 2022 at 11:58 PM Fangrui Song via Gcc-patches
wrote:
>
> From: Fangrui Song
>
> SHF_COMPRESSED style zlib has been supported since binutils 2.26
> and the legacy zlib-gnu option hasn't gain adoption.
> According to Debian Code Search (`gz=zlib-gnu`), no project uses
> -gz=zlib-gnu
On Tue, Jul 5, 2022 at 8:16 AM Tamar Christina via Gcc-patches
wrote:
>
>
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Monday, June 20, 2022 9:57 AM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd
> > Subject: Re: [PATCH]middle-end simplify complex if expressi
On Wed, Jul 6, 2022 at 9:06 AM Tamar Christina wrote:
>
> > -Original Message-
> > From: Andrew Pinski
> > Sent: Wednesday, July 6, 2022 3:10 AM
> > To: Tamar Christina
> > Cc: Richard Biener ; nd ; gcc-
> > patc...@gcc.gnu.org
> > Subject: Re: [PATCH]middle-end simplify complex if expre
On Wed, Jul 13, 2022 at 12:26 PM Sam Feifer via Gcc-patches
wrote:
>
> This patch is intended to fix a missed optimization in match.pd. It optimizes
> (x >= 0 ? x : 0) + (x <= 0 ? -x : 0) to just abs(x). I had to write a second
> simplification in match.pd to handle the commutative property as t
On Thu, Jul 14, 2022 at 7:09 AM Sam Feifer wrote:
>
>
> On Wed, Jul 13, 2022 at 3:36 PM Andrew Pinski wrote:
>>
>> On Wed, Jul 13, 2022 at 12:26 PM Sam Feifer via Gcc-patches
>> wrote:
>> >
>> > This patch is intended to fix a missed optimization in match.pd. It
>> > optimizes (x >= 0 ? x : 0)
On Thu, Jul 14, 2022 at 12:38 PM Sam Feifer wrote:
>
>
>
> On Thu, Jul 14, 2022 at 1:24 PM Andrew Pinski wrote:
>>
>> On Thu, Jul 14, 2022 at 7:09 AM Sam Feifer wrote:
>> >
>> >
>> > On Wed, Jul 13, 2022 at 3:36 PM Andrew Pinski wrote:
>> >>
>> >> On Wed, Jul 13, 2022 at 12:26 PM Sam Feifer via
On Mon, Jul 25, 2022 at 11:01 AM Tom Honermann via Gcc-patches
wrote:
>
> This patch corrects handling of UTF-8 character literals in preprocessing
> directives so that they are treated as unsigned types in char8_t enabled
> C++ modes (C++17 with -fchar8_t or C++20 without -fno-char8_t). Previousl
On Mon, Jul 25, 2022 at 12:37 PM Sam Feifer via Gcc-patches
wrote:
>
> This patch fixes a missed optimization in match.pd. It takes the pattern, x /
> y * y == x, and optimizes it to x % y == 0. This produces fewer instructions.
>
> There are also tests for the optimizations to be added to the te
On Mon, Jul 25, 2022 at 1:59 PM Sam Feifer wrote:
>
>
>> I suspect for eq and mult you might want to add :c to them even though
>> in your testcase you don't need them, you might be able to get it via
>> using different statements and looking at the forwprop gimple dump.
>> Also, did you send the
On Wed, Aug 2, 2023 at 10:13 AM Prathamesh Kulkarni via Gcc-patches
wrote:
>
> On Mon, 31 Jul 2023 at 22:39, Andrew Pinski via Gcc-patches
> wrote:
> >
> > This is a new version of the patch.
> > Instead of doing the matching of inversion comparison directly insid
On Wed, Aug 2, 2023 at 10:14 AM Andrew Pinski wrote:
>
> On Wed, Aug 2, 2023 at 10:13 AM Prathamesh Kulkarni via Gcc-patches
> wrote:
> >
> > On Mon, 31 Jul 2023 at 22:39, Andrew Pinski via Gcc-patches
> > wrote:
> > >
> > > This is a new ver
On Wed, Aug 2, 2023 at 1:25 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Wed, Aug 02, 2023 at 10:04:26AM +0200, Richard Biener via Gcc-patches
> wrote:
> > > --- a/gcc/match.pd
> > > +++ b/gcc/match.pd
> > > @@ -1157,8 +1157,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> > >
> > > /* Simplify ~X
This moves a few simple patterns that are done in value replacement
in phiopt over to match.pd. Just the simple ones which might show up
in other code.
This allows some optimizations to happen even without depending
on sinking from happening and in some cases where phiopt is not
invoked (cond-1.c
As Jakub noticed in
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626039.html
what I did was not totally correct because sometimes chosing the wrong type.
So to get back to what the original code but keeping around the use of
bitwise_inverted_equal_p,
we just need to check if the types of
So I didn't expect valueization to cause calling gimple_nop_convert
to iterate between 2 different SSA names causing an infinite loop
in gimple_bitwise_inverted_equal_p.
So we should cause a bound on gimple_bitwise_inverted_equal_p calling
gimple_nop_convert and only look through one rather than al
On Wed, Aug 2, 2023 at 11:10 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 8/2/23 17:52, Andrew Pinski via Gcc-patches wrote:
> > This moves a few simple patterns that are done in value replacement
> > in phiopt over to match.pd. Just the simple ones which might s
On Thu, Aug 3, 2023 at 12:23 AM Richard Biener via Gcc-patches
wrote:
>
> On Thu, Aug 3, 2023 at 4:34 AM Andrew Pinski via Gcc-patches
> wrote:
> >
> > So I didn't expect valueization to cause calling gimple_nop_convert
> > to iterate between 2 different SSA names
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
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 regressi
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
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 RT
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 tree-optimization/96695
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 to
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 r14-2501-g285c9
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 re
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 I
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 t
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 const
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]:
> #
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 x86
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 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 optimizat
1 - 100 of 549 matches
Mail list logo
