Pushed, thanks :)
On Mon, Jul 31, 2023 at 2:59 PM juzhe.zh...@rivai.ai
wrote:
>
> ok
>
>
>
> juzhe.zh...@rivai.ai
>
> From: Kito Cheng
> Date: 2023-07-31 14:52
> To: gcc-patches; kito.cheng; juzhe.zhong; rdapp.gcc; pan2.li
> CC: Kito Cheng
> Subject: [PATCH] RISC-V: Return machine_mode rather tha
On Fri, 28 Jul 2023, David Malcolm wrote:
> On Fri, 2023-07-28 at 08:00 +0200, Richard Biener wrote:
> > On Fri, Jul 28, 2023 at 12:23?AM David Malcolm via Gcc-patches
> > wrote:
> > >
> > > On Tue, 2023-04-11 at 08:43 +, Richard Biener wrote:
> > > > On Tue, 4 Apr 2023, David Malcolm wrote:
This patch resolves PR target/110843, an ICE caused by my enhancement to
support AVX512 DImode and SImode rotates in the scalar-to-vector (STV) pass.
Although the vprotate instructions are available on all TARGET_AVX512F
microarchitectures, the V2DI and V4SI variants are only available on the
TARG
Joseph, I would appreciate if you could take a look at this?
This fixes the remaining issues which requires me to turn the
warnings off with -Wno-vla-parameter and -Wno-nonnull in my
projects.
Am Montag, dem 03.04.2023 um 21:34 +0200 schrieb Martin Uecker:
>
> With the relatively new warning
On Fri, 28 Jul 2023, Jakub Jelinek wrote:
> Hi!
>
> The comments about _Atomic _BitInt made me figure out I forgot (although
> earlier was planning to do that) to implement __builtin_clear_padding
> support for _BitInt.
>
> The following patch (incremental to the _BitInt series) does that.
OK.
On Mon, 24 Jul 2023, Jiufu Guo wrote:
>
> Hi Martin,
>
> Not sure about your current option about re-using the ipa-sra code
> in the light-expander-sra. And if anything I could input please
> let me know.
>
> And I'm thinking about the difference between the expander-sra, ipa-sra
> and tree-sra
Hao Liu OS writes:
>> Which test case do you see this for? The two tests in the patch still
>> seem to report correct latencies for me if I make the change above.
>
> Not the newly added tests. It is still the existing case causing the
> previous ICE (i.e. assertion problem): gcc.target/aarch64
Sure, the helper makes the code simpler. I'll test the new patch and push if
there is no other issue.
Thanks,
Hao
From: Richard Sandiford
Sent: Monday, July 31, 2023 17:11
To: Hao Liu OS
Cc: Richard Biener; GCC-patches@gcc.gnu.org
Subject: Re: [PATCH] A
On Fri, 28 Jul 2023, Juzhe-Zhong wrote:
> Hi, Richard and Richi.
>
> Base on the suggestions from Richard:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625396.html
>
> This patch choose (1) approach that Richard provided, meaning:
>
> RVV implements cond_* optabs as expanders. RVV the
On Tue, 25 Jul 2023, Richard Sandiford wrote:
> ??? writes:
> > Hi, Richi. Thank you so much for review.
> >
> >>> This function doesn't seem to care about conditional vectorization
> >>> support, so why are you changing it?
> >
> > I debug and analyze the code here:
> >
> > Breakpoint 1, vectori
On Sat, Jul 29, 2023 at 8:22 PM Andrew Pinski via Gcc-patches
wrote:
>
> 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 add
On Sun, 30 Jul 2023, Uros Bizjak wrote:
> Also introduce -m[no-]mmxfp-with-sse option to disable trapping V2SF
> named patterns in order to avoid generation of partial vector V4SFmode
> trapping instructions.
>
> The new option is enabled by default, because even with sanitization,
> a small but
Add POLY_INT_CST support to code within
fold_ctor_reference. This code previously
only supported INTEGER_CST which caused a
bug when using VEC_PERM_EXPR with SVE vectors.
gcc/ChangeLog:
* gimple-fold.cc (fold_ctor_reference):
Add support for Poly_int.
##
Hi, Richard. Thanks a lot for the comment
>> In your code above
>> you either use cond_len_fn or get_len_internal_fn (cond_fn) but
>> isn't that the very same?! So how come you in one case add two
>> and in the other add four args?
cond_len_fn is not the same as get_len_internal_fn (cond_fn) whe
Richard Ball writes:
> Add POLY_INT_CST support to code within
> fold_ctor_reference. This code previously
> only supported INTEGER_CST which caused a
> bug when using VEC_PERM_EXPR with SVE vectors.
Just to add for others: this is a prerequisite for a follow-on patch,
so the change will be teste
On Mon, Jul 31, 2023 at 11:40 AM Richard Biener wrote:
>
> On Sun, 30 Jul 2023, Uros Bizjak wrote:
>
> > Also introduce -m[no-]mmxfp-with-sse option to disable trapping V2SF
> > named patterns in order to avoid generation of partial vector V4SFmode
> > trapping instructions.
> >
> > The new option
juzhe.zh...@rivai.ai writes:
> From: Ju-Zhe Zhong
>
> Hi, Richard and Richi.
>
> Base on previous disscussions, we should make COND_* and COND_LEN_*
> consistent.
>
> So, this patch define these internal function together by these 2
> wrappers:
>
> #ifndef DEF_INTERNAL_COND_FN
> #define DEF_INTERN
Juzhe-Zhong writes:
> Hi, Richard and Richi.
>
> Base on the suggestions from Richard:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625396.html
>
> This patch choose (1) approach that Richard provided, meaning:
>
> RVV implements cond_* optabs as expanders. RVV therefore supports
> both
On Mon, 31 Jul 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richard. Thanks a lot for the comment
>
> >> In your code above
> >> you either use cond_len_fn or get_len_internal_fn (cond_fn) but
> >> isn't that the very same?! So how come you in one case add two
> >> and in the other add four args?
>
On Mon, Jul 31, 2023 at 7:35 AM Andrew Pinski via Gcc-patches
wrote:
>
> 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
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 match rather than just during
> reassoc/ifcombine.
>
> OK? Bootstrapped and tested on x86_64-linux-gnu with no regr
On Tue, 25 Jul 2023, Richard Biener wrote:
> The following removes the code checking whether a noop copy
> is between something involved in the return sequence composed
> of a SET and USE. Instead of checking for this special-case
> the following makes us only ever remove noop copies between
> ps
On Tue, 25 Jul 2023, Richard Biener wrote:
> The following applies a micro-optimization to find_hard_regno_for_1,
> re-ordering the check so we can easily jump-thread by using an else.
> This reduces the time spent in this function by 15% for the testcase
> in the PR.
>
> Bootstrap & regtest runn
>> Ah. So then just feed it cond_fn? I mean, we don't have
>> LEN_FMA, the only LEN-but-not-MASK ifns are those used by
>> power/s390, LEN_LOAD and LEN_STORE?
Yes, that's why I feed cond_fn with get_len_internal_fn (cond_fn)
>> Yes, but all of this depends on what the original ifn is, no?
Yes.
Get_or_insert method is already supported by the unordered hash map.
Adding it to the ordered map enables us to replace the unordered map
with the ordered one in cases where ordering may be useful.
Signed-off-by: Andrzej Turko
gcc/ChangeLog:
* ordered-hash-map.h: Add get_or_insert.
So far genmatch has been using an unordered map to store information about
functions to be generated. Since corresponding locations from match.pd were
used as keys in the map, even small changes to match.pd which caused
line number changes would change the order in which the functions are
generated
The following reduces the number of object files that need to be rebuilt
after match.pd has been modified. Right now a change to match.pd which
adds/removes a line almost always forces recompilation of all files that
genmatch generates from it. This is because of unnecessary changes to
the generate
Currently fprintf calls logging to a dump file take line numbers
in the match.pd file directly as arguments.
When match.pd is edited, referenced code changes line numbers,
which causes changes to many fprintf calls and, thus, to many
(usually all) .cc files generated by genmatch. This forces make
t
On Mon, 31 Jul 2023, Kito Cheng via Gcc-patches wrote:
> Pushed, thanks :)
This breaks compilation:
.../gcc/config/riscv/riscv-v.cc: In function 'void
riscv_vector::expand_vec_series(rtx, rtx, rtx)':
.../gcc/config/riscv/riscv-v.cc:1251:16: error: unused variable 'mask_mode'
[-Werror=unused-v
Hi Dave,
On Fri, Jul 21, 2023 at 10:10 PM David Malcolm wrote:
[...]
It looks like something's gone wrong with the indentation in the above:
> previously we had tab characters, but now I'm seeing a pair of spaces,
> which means this wouldn't line up properly. This might be a glitch
> somewhere
Ok . Thanks Richard.
Could you give me a case that SVE can vectorize a reduction with FMA?
Meaning it will go into vectorize_call and vectorize FMA into COND_FMA ?
I tried many times to reproduce such cases but I failed.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-07-31 1
On Mon, 31 Jul 2023, juzhe.zh...@rivai.ai wrote:
> Ok . Thanks Richard.
>
> Could you give me a case that SVE can vectorize a reduction with FMA?
> Meaning it will go into vectorize_call and vectorize FMA into COND_FMA ?
>
> I tried many times to reproduce such cases but I failed.
I think you n
This patch is inspired by "lowerCTPOP" in LLVM.
Support popcount auto-vectorization by following LLVM approach.
https://godbolt.org/z/3K3GzvY7f
Before this patch:
:7:21: missed: couldn't vectorize loop
:8:14: missed: not vectorized: relevant stmt not supported: _5 =
__builtin_popcount (_4);
Aft
On Thu, 27 Jul 2023 at 12:04, Richard Biener wrote:
>
> On Wed, 26 Jul 2023, Prathamesh Kulkarni wrote:
>
> > Sorry, I meant PR110280 in subject line (not PR10280).
>
> OK after 13.2 is released and the branch is open again.
Thanks, committed the patch to releases/gcc-13 branch in:
https://gcc.gnu
Hi, Richi.
>> I think you need to use fma from math.h together with -ffast-math
>>to get fma.
As you said, this is one of the case I tried:
https://godbolt.org/z/xMzrrv5dT
GCC failed to vectorize.
Could you help me with this?
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-07-
Thanks your comments, Jeff and Robin
> > Is the mulh case somehow common or critical?
> Well, I would actually back up even further. What were the
> circumstances that led to the mulh with a zero operand?
I think you both mentioned why should we add the mulh * 0 simplify.
Unfortunately, I hav
Committed, thanks Richard.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Richard Sandiford via Gcc-patches
Sent: Monday, July 31, 2023 6:17 PM
To: juzhe.zh...@rivai.ai
Cc: gcc-patches@gcc.gnu.org; rguent...@suse.de
Subject: Re: [PATCH] internal-fn: Refine macro define of COND_*
Fix bugs:
../../../riscv-gcc/gcc/config/riscv/riscv-v.cc: In function ???void
riscv_vector::emit_vlmax_masked_fp_mu_insn(unsigned int, int, rtx_def**)???:
../../../riscv-gcc/gcc/config/riscv/riscv-v.cc:999:54: error: request for
member ???require??? in ???riscv_vector::get_mask_mode(dest_mode)???
statement_sink_location for loads is currently confused about
stores that are not on the paths we are sinking across. The
following avoids this by explicitely checking whether a block
with a store is on any of those paths. To not perform too many
walks over the sub-part of the CFG between the ori
Ooops, I guess my code base was too old, and forgot to check that after
rebase, thanks for fix that!
Juzhe-Zhong 於 2023年7月31日 週一，20:21寫道：
> Fix bugs:
> ../../../riscv-gcc/gcc/config/riscv/riscv-v.cc: In function ‘void
> riscv_vector::emit_vlmax_masked_fp_mu_insn(unsigned int, int, rtx_def**)’:
>
ping
On Mon, Jun 19, 2023 at 04:23:57PM +0200, Stefan Schulze Frielinghaus wrote:
> Comparisons between memory and constants might be done in a smaller mode
> resulting in smaller constants which might finally end up as immediates
> instead of in the literal pool.
>
> For example, on s390x a non-
On Mon, 31 Jul 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richi.
>
> >> I think you need to use fma from math.h together with -ffast-math
> >>to get fma.
>
> As you said, this is one of the case I tried:
> https://godbolt.org/z/xMzrrv5dT
> GCC failed to vectorize.
>
> Could you help me with this?
On Mon, Jul 31, 2023 at 8:03 PM Juzhe-Zhong wrote:
>
> This patch is inspired by "lowerCTPOP" in LLVM.
> Support popcount auto-vectorization by following LLVM approach.
> https://godbolt.org/z/3K3GzvY7f
>
> Before this patch:
>
> :7:21: missed: couldn't vectorize loop
> :8:14: missed: not vectoriz
On Mon, Jul 31, 2023 at 1:06 PM Andrzej Turko via Gcc-patches
wrote:
>
> Get_or_insert method is already supported by the unordered hash map.
> Adding it to the ordered map enables us to replace the unordered map
> with the ordered one in cases where ordering may be useful.
OK. Note the Makefile
On Mon, Jul 31, 2023 at 1:06 PM Andrzej Turko via Gcc-patches
wrote:
>
> So far genmatch has been using an unordered map to store information about
> functions to be generated. Since corresponding locations from match.pd were
> used as keys in the map, even small changes to match.pd which caused
>
Yeah. I have tried this case too.
But this case doesn't need to be vectorized as COND_FMA, am I right?
The thing I wonder is that whether this condtion:
if (mask_opno >= 0 && reduc_idx >= 0)
or similar as len
if (len_opno >= 0 && reduc_idx >= 0)
Whether they are redundant in vectorizable_cal
I saw you didn't push yet, so I pushed another patch to fix those
unused variable issues.
On Mon, Jul 31, 2023 at 9:12 PM Kito Cheng wrote:
>
> Ooops, I guess my code base was too old, and forgot to check that after
> rebase, thanks for fix that!
>
> Juzhe-Zhong 於 2023年7月31日 週一，20:21寫道：
>>
>> Fi
Hi Maciej:
Sorry for disturbing, pushed a fix for that, and...added
-Werror=unused-variable to my build script to prevent that happen
again :(
On Mon, Jul 31, 2023 at 7:08 PM Maciej W. Rozycki wrote:
>
> On Mon, 31 Jul 2023, Kito Cheng via Gcc-patches wrote:
>
> > Pushed, thanks :)
>
> This bre
Ok. Thanks. Li Pan is still testing.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-31 21:45
To: Kito Cheng
CC: Juzhe-Zhong; gcc-patches; jeffreyalaw; macro; pan2.li; rdapp.gcc
Subject: Re: [committed] RISC-V: Fix bug of get_mask_mode
I saw you didn't push yet, so I pushed another pa
On Mon, Jul 31, 2023 at 1:07 PM Andrzej Turko via Gcc-patches
wrote:
>
> Currently fprintf calls logging to a dump file take line numbers
> in the match.pd file directly as arguments.
> When match.pd is edited, referenced code changes line numbers,
> which causes changes to many fprintf calls and,
>> Drop outer loop if word_size never larger than 1?
Yeah. we never have TI vector modes for now.
The codes I just directly copy from LLVM in generic intrinsic handling :)
since LLVM generic code is considering handling INT128 vector
I will remove all redundant code for INT128 vector mode in
On Mon, 31 Jul 2023, ??? wrote:
> Yeah. I have tried this case too.
>
> But this case doesn't need to be vectorized as COND_FMA, am I right?
Only when you enable loop masking. Alternatively use
double foo (double *a, double *b, double *c)
{
double result = 0.0;
for (int i = 0; i < 1024; ++
On 6/19/23 08:23, Stefan Schulze Frielinghaus via Gcc-patches wrote:
Comparisons between memory and constants might be done in a smaller mode
resulting in smaller constants which might finally end up as immediates
instead of in the literal pool.
For example, on s390x a non-symmetric compariso
The following makes sure to limit the shift operand when vectorizing
(short)((int)x >> 31) via (short)x >> 31 as the out of bounds shift
operand otherwise invokes undefined behavior. When we determine
whether we can demote the operand we know we at most shift in the
sign bit so we can adjust the s
On Mon, 31 Jul 2023, Kito Cheng wrote:
> Sorry for disturbing, pushed a fix for that, and...added
> -Werror=unused-variable to my build script to prevent that happen
> again :(
I just configure with `--enable-werror-always', which we want to keep
our standards up to anyway, but if you find this
This patch is inspired by "lowerCTPOP" in LLVM.
Support popcount auto-vectorization by LLVM approach.
Before this patch:
:7:21: missed: couldn't vectorize loop
:8:14: missed: not vectorized: relevant stmt not supported: _5 =
__builtin_popcount (_4);
After this patch:
popcount_32:
ble
Oh, Thanks a lot.
I can test it in RISC-V backend now.
But I have another questions:
>> I'm a bit confused (but also by the existing mask code), whether
>>vect_nargs needs adjustment depends on the IFN in the IL we analyze.
>>If if-conversion recognizes a .COND_ADD then we need to add nothing
>>fo
Address comment and fix on V2:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625870.html
Ok for trunk?
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-31 21:38
To: Juzhe-Zhong
CC: gcc-patches; kito.cheng; jeffreyalaw; rdapp.gcc
Subject: Re: [PATCH] RISC-V: Support POPCOUNT auto-vect
Hello,
On Fri, 28 Jul 2023, Martin Uecker wrote:
> > > Sorry, somehow I must be missing something here.
> > >
> > > If you add something you would create a new value and this may (in
> > > an object) have random new padding. But the "expected" value should
> > > be updated by a failed atomic_co
PING * 2
On Tue, Jul 25, 2023 at 8:32 AM Aldy Hernandez wrote:
>
> Ping
>
> On Mon, Jul 17, 2023, 15:14 Aldy Hernandez wrote:
>>
>> Instead of reading the known zero bits in IPA, read the value/mask
>> pair which is available.
>>
>> There is a slight change of behavior here. I have removed the
Hey Joseph,
On Fri, Jul 28 2023 at 08:32:31 PM +00:00:00, Joseph Myers
wrote:
OK.
--
Joseph S. Myers
jos...@codesourcery.com
Since I don't have write access, do you mind pushing this for me?
On Mon, Jul 31, 2023 at 10:03 PM Maciej W. Rozycki wrote:
>
> On Mon, 31 Jul 2023, Kito Cheng wrote:
>
> > Sorry for disturbing, pushed a fix for that, and...added
> > -Werror=unused-variable to my build script to prevent that happen
> > again :(
>
> I just configure with `--enable-werror-always'
On 7/31/23 08:52, Kito Cheng via Gcc-patches wrote:
On Mon, Jul 31, 2023 at 10:03 PM Maciej W. Rozycki wrote:
On Mon, 31 Jul 2023, Kito Cheng wrote:
Sorry for disturbing, pushed a fix for that, and...added
-Werror=unused-variable to my build script to prevent that happen
again :(
I ju
On 7/31/23 08:01, Richard Biener via Gcc-patches wrote:
The following makes sure to limit the shift operand when vectorizing
(short)((int)x >> 31) via (short)x >> 31 as the out of bounds shift
operand otherwise invokes undefined behavior. When we determine
whether we can demote the operand we
On 7/28/23 01:05, Richard Biener via Gcc-patches wrote:
The following delays sinking of loads within the same innermost
loop when it was unconditional before. That's a not uncommon
issue preventing vectorization when masked loads are not available.
Bootstrapped and tested on x86_64-unknown-l
Am Montag, dem 31.07.2023 um 14:33 + schrieb Michael Matz:
> Hello,
>
> On Fri, 28 Jul 2023, Martin Uecker wrote:
>
> > > > Sorry, somehow I must be missing something here.
> > > >
> > > > If you add something you would create a new value and this may (in
> > > > an object) have random new p
On 7/31/23 06:14, Wang, Yanzhang wrote:
Thanks your comments, Jeff and Robin
Is the mulh case somehow common or critical?
Well, I would actually back up even further. What were the
circumstances that led to the mulh with a zero operand?
I think you both mentioned why should we add the mu
On Mon, 31 Jul 2023, Kito Cheng wrote:
> > I just configure with `--enable-werror-always', which we want to keep
> > our standards up to anyway,
>
> I rely on the host GCC which is 11 relatively old compared to the
> trunk, so --enable-werror-always will get many -Wformat* warning :(
If buildi
On Mon, 31 Jul 2023, Jeff Law wrote:
> > That's a good suggestion! Thanks, let me try to apply myself workflow :)
> I'm thinking that as part of the CI POC being done by RISE that the base AMI
> image ought to be gcc-13 based and that we should configure the toolchains we
> build with -enable-wer
On Fri, 28 Jul 2023, Jason Merrill via Gcc-patches wrote:
> > Thanks, I had thought there could be a potential issue with needing to also
> > check cpp_get_options(pfile)->traditional. But looking at it more, there's
> > no
> > code path currently that can end up here in traditional mode, so yes w
On 7/31/23 04:54, Richard Biener via Gcc-patches wrote:
On Tue, 25 Jul 2023, Richard Biener wrote:
The following applies a micro-optimization to find_hard_regno_for_1,
re-ordering the check so we can easily jump-thread by using an else.
This reduces the time spent in this function by 15% for
On 7/31/23 04:53, Richard Biener via Gcc-patches wrote:
On Tue, 25 Jul 2023, Richard Biener wrote:
The following removes the code checking whether a noop copy
is between something involved in the return sequence composed
of a SET and USE. Instead of checking for this special-case
the follow
On 7/28/23 04:17, Robin Dapp via Gcc-patches wrote:
Hi,
this patch extracts the hoist-pressure handling from gcse and puts it
into a separate file so it can be used by other passes in the future.
No functional change and I also abstained from c++ifying the code.
The naming with the regpressur
The fold_using_range operand fetching mechanism has a variety of modes.
The "normal" mechanism simply invokes the current or supplied
range_query to satisfy fetching current range info for any ssa-names
used during the evalaution of the statement,
I also added support for fur_list which allow
GCC 13.2 released[2] so I merged the series now that the branch is unfrozen.
Thanks,
Patrick
[2] https://inbox.sourceware.org/gcc/ZMJeq%2FY5SN+7i8a+@tucnak/T/#u
On 7/25/23 11:01, Patrick O'Neill wrote:
Discussed during the weekly RISC-V GCC meeting[1] and pre-approved by
Jeff Law.
If there are
On Mon, 31 Jul 2023, Martin Uecker via Gcc-patches wrote:
> Joseph, I would appreciate if you could take a look at this?
>
> This fixes the remaining issues which requires me to turn the
> warnings off with -Wno-vla-parameter and -Wno-nonnull in my
> projects.
The front-end changes are OK.
--
Hi, Sid and Jakub,
I have a question in the following source portion of the routine
“addr_object_size” of gcc/tree-object-size.cc:
743 bytes = compute_object_offset (TREE_OPERAND (ptr, 0), var);
744 if (bytes != error_mark_node)
745 {
746 bytes = size_for_offset
Hello,
On Tue, Jul 18 2023, Aldy Hernandez wrote:
> On 7/17/23 15:14, Aldy Hernandez wrote:
>> Instead of reading the known zero bits in IPA, read the value/mask
>> pair which is available.
>>
>> There is a slight change of behavior here. I have removed the check
>> for SSA_NAME, as the ranger c
On 7/28/23 15:11, Joseph Myers wrote:
This patch is OK.
I fixed the whitespace errors in the patch as well as a couple minor
ChangeLog entry items and pushed Costas's patch to the trunk.
jeff
On 2023-07-31 12:47, Qing Zhao wrote:
Hi, Sid and Jakub,
I have a question in the following source portion of the routine
“addr_object_size” of gcc/tree-object-size.cc:
743 bytes = compute_object_offset (TREE_OPERAND (ptr, 0), var);
744 if (bytes != error_mark_node)
745
Hi,
when IPA-SRA detects whether a parameter passed by reference is
written to, it does not special case CLOBBERs which means it often
bails out unnecessarily, especially when dealing with C++ destructors.
Fixed by the obvious continue in the two relevant loops.
The (slightly) more complex testca
On 2023-07-31 13:03, Siddhesh Poyarekar wrote:
On 2023-07-31 12:47, Qing Zhao wrote:
Hi, Sid and Jakub,
I have a question in the following source portion of the routine
“addr_object_size” of gcc/tree-object-size.cc:
743 bytes = compute_object_offset (TREE_OPERAND (ptr, 0), var);
74
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 match rather than just during
>
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:
Hi, Sid,
Thanks a lot.
> On Jul 31, 2023, at 1:07 PM, Siddhesh Poyarekar wrote:
>
> On 2023-07-31 13:03, Siddhesh Poyarekar wrote:
>> On 2023-07-31 12:47, Qing Zhao wrote:
>>> Hi, Sid and Jakub,
>>>
>>> I have a question in the following source portion of the routine
>>> “addr_object_size” of
On 2023-07-31 14:13, Qing Zhao wrote:
Okay. I see.
Then if the size info from the TYPE is smaller than the size info from the
malloc,
then based on the current code, we use the smaller one between these two,
i.e, the size info from the TYPE. (Even for the OST_MAXIMUM).
Is such behavior co
> On Jul 31, 2023, at 2:23 PM, Siddhesh Poyarekar wrote:
>
> On 2023-07-31 14:13, Qing Zhao wrote:
>> Okay. I see.
>> Then if the size info from the TYPE is smaller than the size info from the
>> malloc,
>> then based on the current code, we use the smaller one between these two,
>> i.e, the
On Mon, 31 Jul 2023, Hamza Mahfooz wrote:
> Hey Joseph,
>
> On Fri, Jul 28 2023 at 08:32:31 PM +00:00:00, Joseph Myers
> wrote:
> > > OK.
> >
> > --
> > Joseph S. Myers
> > jos...@codesourcery.com
>
> Since I don't have write access, do you mind pushing this for me?
Done.
--
Joseph S. Myers
Hi Juzhe,
> +/* Expand Vector POPCOUNT by parallel popcnt:
> +
> + int parallel_popcnt(uint32_t n) {
> + #define POW2(c) (1U << (c))
> + #define MASK(c) (static_cast(-1) / (POW2(POW2(c)) + 1U))
> + #define COUNT(x, c) ((x) & MASK(c)) + (((x)>>(POW2(c))) & MASK(c))
> + n = CO
On 2023-07-21 07:21, Martin Uecker via Gcc-patches wrote:
This patch adds a warning for allocations with insufficient size
based on the "alloc_size" attribute and the type of the pointer
the result is assigned to. While it is theoretically legal to
assign to the wrong pointer type and cast it t
Am Montag, dem 31.07.2023 um 15:39 -0400 schrieb Siddhesh Poyarekar:
> On 2023-07-21 07:21, Martin Uecker via Gcc-patches wrote:
> >
> >
> > This patch adds a warning for allocations with insufficient size
> > based on the "alloc_size" attribute and the type of the pointer
> > the result is assig
Hi,
After some detailed study and consideration on how to use the new attribute
“counted_by”
in __builtin_dynamic_object_size, I came up with the following example with
detailed explanation
on the expected behavior from GCC on using this new attribute.
Please take a look on this example and
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
> +/* FIXME: We don't allow vectorize "__builtin_popcountll" yet since it needs
> "vec_pack_trunc" support
> + and such pattern may cause inferior codegen.
> + We will enable "vec_pack_trunc" when we support reasonable vector
> cost model. */
Wait, why do we need vec_pack_trunc f
On Fri, 21 Jul 2023 at 16:52, Martin Uecker via Gcc-patches
wrote:
>
>
>
> This patch adds a warning for allocations with insufficient size
> based on the "alloc_size" attribute and the type of the pointer
> the result is assigned to. While it is theoretically legal to
> assign to the wrong pointe
On Mon, 19 Jun 2023 at 19:59, Stefan Schulze Frielinghaus via
Gcc-patches wrote:
>
> Comparisons between memory and constants might be done in a smaller mode
> resulting in smaller constants which might finally end up as immediates
> instead of in the literal pool.
>
> For example, on s390x a non-
On Tue, 1 Aug 2023 at 03:13, Prathamesh Kulkarni
wrote:
>
> On Mon, 19 Jun 2023 at 19:59, Stefan Schulze Frielinghaus via
> Gcc-patches wrote:
> >
> > Comparisons between memory and constants might be done in a smaller mode
> > resulting in smaller constants which might finally end up as immediat
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Now that cp_parser_constant_expression accepts a null non_constant_p,
we can transitively remove dummy arguments in the call chain.
Running dg.exp and counting the # of is_rvalue_constant_expression calls
from cp_parser_consta
1 - 100 of 121 matches
Mail list logo
