vfwadd needs to depend on FRM???
Did you check SPIKE ? I am not sure since I think vfwadd never overflow.
Besides, do you check the MD pattern has include dependency of FRM_REGNUM?
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-02 14:35
To: gcc-patches
CC: juzhe.zhong; kito.cheng; pan2.li;
Hi,
Loop distribution and ifcvt introduces verisons of loops which may be removed
later if vectorization fails. Ifcvt does this by temporarily breaking profile
and producing conditional that has two arms with 100% probability because we
know one of the versions will be removed.
Loop distribution
> vfwadd needs to depend on FRM???
> Did you check SPIKE ? I am not sure since I think vfwadd never overflow.
The VI_VFP_VF_LOOP_WIDE depends on VI_VFP_COMMON, which has required
STATE.frm->read(). AFAIK, the precision will also result in rounding as
floating is discretized by design. For exampl
On Mon, 31 Jul 2023, ??? wrote:
> 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 recogniz
Ok. LGTM.
juzhe.zh...@rivai.ai
From: Li, Pan2
Date: 2023-08-02 15:38
To: juzhe.zh...@rivai.ai; gcc-patches
CC: Kito.cheng; Wang, Yanzhang
Subject: RE: [PATCH v2] RISC-V: Support RVV VFWADD rounding mode intrinsic API
> vfwadd needs to depend on FRM???
> Did you check SPIKE ? I am not sure sinc
From: Pan Li
This patch would like to enhance the vfsub/vfrsub rounding API test for
below 2 purposes.
* The non-rm API has no frm related insn generated.
* The rm API has the frm backup/restore/set insn generated.
Signed-off-by: Pan Li
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv
On Mon, Jul 31, 2023 at 7:05 PM Martin Jambor wrote:
>
> 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 cont
On Mon, Jul 31, 2023 at 7:47 PM Andrew Pinski via Gcc-patches
wrote:
>
> 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?
On Mon, Jul 31, 2023 at 7:47 PM Andrew Pinski via Gcc-patches
wrote:
>
> 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 ha
On Mon, Jul 31, 2023 at 10:17 PM Andrew Pinski via Gcc-patches
wrote:
>
> 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;
On Tue, Aug 1, 2023 at 2:36 AM Patrick Palka via Gcc-patches
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> In the C++ front end, a COMPONENT_REF's second operand isn't always a
> decl (at least at template parse time). This patch makes the generic
> prett
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Wednesday, August 2, 2023 3:50 PM
To: Li, Pan2 ; gcc-patches
Cc: Kito.cheng ; Wang, Yanzhang
Subject: Re: RE: [PATCH v2] RISC-V: Support RVV VFWADD rounding mode intrinsic
API
Ok. LGTM.
juzhe.zh..
On Mon, 31 Jul 2023, Jeff Law wrote:
>
>
> 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 els
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 & X as zero. */
> > (simplify
> > - (bit_and:c (convert? @0) (convert? (bit_not @0))
Thanks Richard so much.
Forgive me asking question again :)
Is this following code correct for you ?
+ if (len_loop_p)
+{
+ if (len_opno >= 0)
+ {
+ ifn = cond_len_fn;
+ /* COND_* -> COND_LEN_* takes 2 extra arguments:LEN,BIAS. */
+ vect_nargs += 2;
+
On Wed, 2 Aug 2023, juzhe.zh...@rivai.ai wrote:
> Thanks Richard so much.
>
> Forgive me asking question again :)
>
> Is this following code correct for you ?
Well, I wonder what kind of testcase runs into the reduc_idx >= 0 case.
The point is I don't _know_ whether the code is correct, in fact
There are two kinds of pause bottleneck, one is in user space, the other
is in kernel. Tpause plus backoff could reduce loop count in user space.
To kernel, Because tasks start at same time, they usually arrive critial
area at same time, this decrease performance. tasks started one by one
could avo
Yes. I also suspect whether we can run into reduc_idx >= 0.
I will add gcc_unreachable () and add fully testcase for it.
After I have fully tested in RISC-V port then send V4.
Thank you so much.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-08-02 16:33
To: juzhe.zh...@rivai.ai
CC: ri
Consider Signed-off-by lines as part of the ending of the initial
commit to avoid having these in the middle of the log when the
changelog part is injected after.
This is particularly usefull with:
$ git gcc-commit-mklog --amend -s
that can be used to create the changelog and add the Signed-off
Ping.
> -Original Message-
> From: Tamar Christina
> Sent: Wednesday, July 26, 2023 8:35 PM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; jos...@codesourcery.com
> Subject: RE: [PATCH 2/2][frontend]: Add novector C pragma
>
> Hi, This is a respin of the patch taking in the f
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
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
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
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.
Jeff Law via Gcc-patches writes:
> On 8/1/23 05:18, Richard Sandiford wrote:
>>
>> Where were you seeing the requirement for pointer equality? genrecog.cc
>> at least uses rtx_equal_p, and I think it has to. E.g. some patterns
>> use (match_dup ...) to match output and input mems, and mem rtxes
From: Pan Li
This patch would like to support the rounding mode API for the VFWSUB
for the below samples.
* __riscv_vfwsub_vv_f64m2_rm
* __riscv_vfwsub_vv_f64m2_rm_m
* __riscv_vfwsub_vf_f64m2_rm
* __riscv_vfwsub_vf_f64m2_rm_m
* __riscv_vfwsub_wv_f64m2_rm
* __riscv_vfwsub_
Hi All,
When determining issue rates we currently discount non-constant MLA accumulators
for Advanced SIMD but don't do it for the latency.
This means the costs for Advanced SIMD with a constant accumulator are wrong and
results in us costing SVE and Advanced SIMD the same. This can cauze us to
Hi All,
boolean comparisons have different cost depending on the mode. e.g.
a && b when predicated doesn't require an addition instruction, the AND is free
by combining the predicate of the one operation into the second one. At the
moment though we only fuse compares so this update requires one o
Hi All,
In GCC 11 we implemented the vectorizer optab for widening left shifts,
however this optab is only supported for uniform shift constants.
At the moment GCC still has two loop vectorization strategy (classical loop and
SLP based loop vec) and the optab is implemented as a scalar pattern.
Hi All,
Currently we segfault when len == 0 for an attribute list.
essentially [cons: =0, 1, 2, 3; attrs: ] segfaults but should be equivalent to
[cons: =0, 1, 2, 3] and [cons: =0, 1, 2, 3; attrs:]. This fixes it by just
returning early and leaving it to the validators whether this should error
Tamar Christina writes:
> Hi All,
>
> When determining issue rates we currently discount non-constant MLA
> accumulators
> for Advanced SIMD but don't do it for the latency.
>
> This means the costs for Advanced SIMD with a constant accumulator are wrong
> and
> results in us costing SVE and Adv
On 26/07/2023 16:26, Jason Merrill wrote:
> On 6/28/23 06:35, Alex Coplan wrote:
> > Hi,
> >
> > This patch implements clang's __has_feature and __has_extension in GCC.
> > This is a v2 of the original RFC posted here:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617878.html
> >
>
> Tamar Christina writes:
> > Hi All,
> >
> > When determining issue rates we currently discount non-constant MLA
> > accumulators for Advanced SIMD but don't do it for the latency.
> >
> > This means the costs for Advanced SIMD with a constant accumulator are
> > wrong and results in us costing S
Tamar Christina writes:
> Hi All,
>
> boolean comparisons have different cost depending on the mode. e.g.
> a && b when predicated doesn't require an addition instruction, the AND is
> free
Nit (for the commit msg): additional
Maybe:
for SVE, a && b doesn't require an additional instruction
Tamar Christina writes:
>> Tamar Christina writes:
>> > Hi All,
>> >
>> > When determining issue rates we currently discount non-constant MLA
>> > accumulators for Advanced SIMD but don't do it for the latency.
>> >
>> > This means the costs for Advanced SIMD with a constant accumulator are
>> >
The only exported PHI allocation already adds the PHI node to a block.
Bootstrapped on x86_64-unknown-linux-gnu, pushed.
* tree-phinodes.h (add_phi_node_to_bb): Remove.
* tree-phinodes.cc (add_phi_node_to_bb): Make static.
---
gcc/tree-phinodes.cc | 3 +--
gcc/tree-phinodes.h |
ACLE has added intrinsics to bridge between SVE and Neon.
The NEON_SVE Bridge adds intrinsics that allow conversions between NEON and
SVE vectors.
This patch adds support to GCC for the following 3 intrinsics:
svset_neonq, svget_neonq and svdup_neonq
gcc/ChangeLog:
* config.gcc: Adds n
Hello,
On Tue, 1 Aug 2023, Joseph Myers wrote:
> > Only because cmpxchg is defined in terms of memcpy/memcmp. If it were
> > defined in terms of the == operator (obviously applied recursively
> > member-wise for structs) and simple-assignment that wouldn't be a problem.
>
> It also wouldn't
On Tue, 1 Aug 2023, Richard Sandiford wrote:
> Richard Sandiford writes:
> > Richard Biener via Gcc-patches writes:
> >> 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 un
On Tue, 1 Aug 2023, Jiufu Guo wrote:
>
> Hi,
>
> Richard Biener writes:
>
> > 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
> >>
The following adds an on-demand global liveness computation class
computing and caching the live-out virtual operand of basic blocks
and answering live-out, live-in and live-on-edge queries. The flow
is optimized for the intended use in code sinking which will query
live-in and possibly can be opt
statement_sink_location for loads is currently confused about
stores that are not on the paths we are sinking across. The
following replaces the logic that tries to ensure we are not
sinking across stores by instead of walking all immediate virtual
uses and then checking whether found stores are o
On Tue, Aug 1, 2023 at 12:15 PM Jan Hubicka via Gcc-patches
wrote:
>
> Hi,
> This patch fixes update after constant peeling in profilogue. We now reached
> 0 profile
> update bugs on tramp3d vectorizaiton and also on quite few testcases, so I am
> enabling the
> testuiste checks so we do not re
On Mon, 31 Jul 2023, Richard Biener wrote:
> 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 man
On 8/1/23 01:20, Surya Kumari Jangala wrote:
Ping
Sorry for delay with the answer. I was on vacation.
On 21/07/23 3:43 pm, Surya Kumari Jangala via Gcc-patches wrote:
The improve_allocation() routine does not update the
allocated_hardreg_p[] array after an allocno is assigned a register.
If
Richard Biener writes:
> On Tue, 1 Aug 2023, Richard Sandiford wrote:
>
>> Richard Sandiford writes:
>> > Richard Biener via Gcc-patches writes:
>> >> 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
>>
LGTM, thanks:)
Pan Li via Gcc-patches 於 2023年8月2日 週三 18:19 寫道：
> From: Pan Li
>
> This patch would like to support the rounding mode API for the VFWSUB
> for the below samples.
>
> * __riscv_vfwsub_vv_f64m2_rm
> * __riscv_vfwsub_vv_f64m2_rm_m
> * __riscv_vfwsub_vf_f64m2_rm
> * _
On 8/2/23 06:50, Richard Biener via Gcc-patches wrote:
On Mon, 31 Jul 2023, Richard Biener wrote:
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 st
In certain cases a constant may not fit into the mode used to perform a
comparison. This may be the case for sign-extended constants which are
used during an unsigned comparison as e.g. in
(set (reg:CC 100 cc)
(compare:CC (mem:SI (reg/v/f:SI 115 [ a ]) [1 *a_4(D)+0 S4 A64])
(const_int
Okay. This previous small example was used to show the correct behavior of
__bos
for Fixed arrays when the allocation size and the TYPE_SIZE are mismatched.
Now we agreed on the correct behavior for each of the cases for the fixed array.
Since the new “counted_by” attribute is mainly a comple
I am concerning:
1. How do you model round to +Inf (avg_floor) and round to -Inf (avg_ceil) ?
2. Is it possible we could use vaadd[u] to model avg ?
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-08-01 22:31
To: gcc-patches; palmer; Kito Cheng; juzhe.zh...@rivai.ai; jeffreyalaw
CC: rdapp.gc
On 8/2/23 07:49, Stefan Schulze Frielinghaus via Gcc-patches wrote:
In certain cases a constant may not fit into the mode used to perform a
comparison. This may be the case for sign-extended constants which are
used during an unsigned comparison as e.g. in
(set (reg:CC 100 cc)
(compare:
Hi all,
I'm pinging to discuss again if we want to move this forward for GCC14.
I did some testing again and I haven't been able to find obvious
regressions, including testing the code from PR86270 and PR70359 that
Richard mentioned.
I still believe that zero can be considered a special case even
Tamar Christina writes:
> Hi All,
>
> In GCC 11 we implemented the vectorizer optab for widening left shifts,
> however this optab is only supported for uniform shift constants.
>
> At the moment GCC still has two loop vectorization strategy (classical loop
> and
> SLP based loop vec) and the opt
Tamar Christina writes:
> Hi All,
>
> Currently we segfault when len == 0 for an attribute list.
>
> essentially [cons: =0, 1, 2, 3; attrs: ] segfaults but should be equivalent to
> [cons: =0, 1, 2, 3] and [cons: =0, 1, 2, 3; attrs:]. This fixes it by just
> returning early and leaving it to the
> On Aug 2, 2023, at 2:25 AM, Martin Uecker wrote:
>
> Am Dienstag, dem 01.08.2023 um 15:45 -0700 schrieb Kees Cook:
>> On Mon, Jul 31, 2023 at 08:14:42PM +, Qing Zhao wrote:
>>> /* In general, Due to type casting, the type for the pointee of a pointer
>>> does not say anything about the
> On Aug 1, 2023, at 6:45 PM, Kees Cook wrote:
>
> On Mon, Jul 31, 2023 at 08:14:42PM +, Qing Zhao wrote:
>> /* In general, Due to type casting, the type for the pointee of a pointer
>> does not say anything about the object it points to,
>> So, __builtin_object_size can not directly us
This patch extends option -mbranch-protection=bti with an optional argument
as bti[+all] to force compiler to unconditionally insert bti for all
functions. Because a direct function call at the stage of compiling might be
rewritten to an indirect call with some kind of linker-generated thunk stub
a
Hi!
On Fri, Jul 28, 2023 at 06:37:23PM +, Joseph Myers wrote:
> Yes, the type used in _Generic isn't fully specified, just the type after
> integer promotions in contexts where those occur.
Ok. I've removed those static_asserts from the test then, no need to test
what isn't fully specified.
On 2023-08-02 20:41, Richard Biener wrote:
On Tue, 1 Aug 2023, Jiufu Guo wrote:
Hi,
Richard Biener writes:
> 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 coul
Revised:
-- Fix indentation problems
-- Add more detail to Changelog
-- Add new test on handling non-CPython code case
-- Turn off debugging inform by default
-- Make on_finish_translation_unit() static
-- Remove superfluous null checks in init_py_structs()
Changes have been bootstrapped and teste
Canonicalizes (signed x << c) >> c into the lowest
precision(type) - c bits of x IF those bits have a mode precision or a
precision of 1. Also combines this rule with (unsigned x << c) >> c -> x &
((unsigned)-1 >> c) to prevent duplicate pattern. Tested successfully on
x86_64 and x86 targets.
PR
Hi Dave,
Thank you for the feedback! I've incorporated the changes and sent a
revised version of the patch.
On Tue, Aug 1, 2023 at 1:02 PM David Malcolm wrote:
>
> On Tue, 2023-08-01 at 09:52 -0400, Eric Feng wrote:
> > Hi all,
> >
> > This patch adds a hook to the end of ana::on_finish_translat
> On Aug 1, 2023, at 10:31 AM, Martin Uecker wrote:
>
> Am Dienstag, dem 01.08.2023 um 13:27 + schrieb Qing Zhao:
>>
>>> On Aug 1, 2023, at 3:51 AM, Martin Uecker via Gcc-patches
>>> wrote:
>>>
>
>
Hi Martin,
Just wondering if it'd be a good idea perhaps to warn if allo
On Thu, Jun 1, 2023 at 2:11 PM Bernhard Reutner-Fischer
wrote:
>
> Hi David, Patrick,
>
> On Thu, 1 Jun 2023 18:33:46 +0200
> Bernhard Reutner-Fischer wrote:
>
> > On Thu, 1 Jun 2023 11:24:06 -0400
> > Patrick Palka wrote:
> >
> > > On Sat, May 13, 2023 at 7:26 PM Bernhard Reutner-Fischer via
>
On 8/2/23 04:05, Richard Sandiford wrote:
Jeff Law via Gcc-patches writes:
On 8/1/23 05:18, Richard Sandiford wrote:
Where were you seeing the requirement for pointer equality? genrecog.cc
at least uses rtx_equal_p, and I think it has to. E.g. some patterns
use (match_dup ...) to match o
On Wed, 2023-08-02 at 12:20 -0400, Eric Feng wrote:
Hi Eric, thanks for the updated patch.
Overall, looks good to me, although I'd drop the "Exited." from the
"sorry" message (and thus from the dg-message directive), since the
compiler is not exiting, it's just the particular plugin that's giving
The NVPTX low latency memory is not accessible outside the team that allocates
it, and therefore should be unavailable for allocators with the access trait
"all". This change means that the omp_low_lat_mem_alloc predefined
allocator now implicitly implies the "pteam" trait.
libgomp/ChangeLog:
This patch series is an updated and reworked version of some of the patch set
posted about a year ago (the other features will be posted soon), this
time supporting amdgcn, in addition to nvptx:
https://patchwork.sourceware.org/project/gcc/list/?series=10748&state=%2A&archive=both
The series impl
This patch adds support for allocating low-latency ".shared" memory on
NVPTX GPU device, via the omp_low_lat_mem_space and omp_alloc. The memory
can be allocated, reallocated, and freed using a basic but fast algorithm,
is thread safe and the size of the low-latency heap can be configured using
t
This implements the OpenMP low-latency memory allocator for AMD GCN using the
small per-team LDS memory (Local Data Store).
Since addresses can now refer to LDS space, the "Global" address space is
no-longer compatible. This patch therefore switches the backend to use
entirely "Flat" addressing
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 inside
> match, creating a new function (bitwise_inverted_equal_p) to do it.
> It is very similar to bitwise_equal_p that was
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 inside
> > match, creating a new funct
On Wed, Aug 02, 2023 at 12:59:28PM -0400, David Malcolm wrote:
> On Wed, 2023-08-02 at 12:20 -0400, Eric Feng wrote:
>
> Hi Eric, thanks for the updated patch.
>
> Overall, looks good to me, although I'd drop the "Exited." from the
> "sorry" message (and thus from the dg-message directive), since
So we're being a bit too aggressive with the .opt zicond patterns.
(define_insn "*czero.eqz..opt1"
[(set (match_operand:GPR 0 "register_operand" "=r")
(if_then_else:GPR (eq (match_operand:X 1 "register_operand" "r")
(const_int 0))
On Wed, 2 Aug 2023, Richard Sandiford wrote:
> Richard Biener writes:
> > On Tue, 1 Aug 2023, Richard Sandiford wrote:
> >
> >> Richard Sandiford writes:
> >> > Richard Biener via Gcc-patches writes:
> >> >> The following makes sure to limit the shift operand when vectorizing
> >> >> (short)((i
On Wed, 2 Aug 2023, Tamar Christina via Gcc-patches wrote:
> Ping.
>
> > -Original Message-
> > From: Tamar Christina
> > Sent: Wednesday, July 26, 2023 8:35 PM
> > To: Tamar Christina ; gcc-patches@gcc.gnu.org
> > Cc: nd ; jos...@codesourcery.com
> > Subject: RE: [PATCH 2/2][frontend]:
Am Mittwoch, dem 02.08.2023 um 16:45 + schrieb Qing Zhao:
>
> > On Aug 1, 2023, at 10:31 AM, Martin Uecker wrote:
> >
> > Am Dienstag, dem 01.08.2023 um 13:27 + schrieb Qing Zhao:
> > >
> > > > On Aug 1, 2023, at 3:51 AM, Martin Uecker via Gcc-patches
> > > > wrote:
> > > >
> >
> >
Revised:
-- Remove superfluous { }
-- Reword diagnostic
---
This patch adds a hook to the end of ana::on_finish_translation_unit
which calls relevant stashing-related callbacks registered during plugin
initialization. This feature is used to stash named types and global
variables for a CPython an
On Wed, Aug 2, 2023 at 1:20 PM Marek Polacek wrote:
>
> On Wed, Aug 02, 2023 at 12:59:28PM -0400, David Malcolm wrote:
> > On Wed, 2023-08-02 at 12:20 -0400, Eric Feng wrote:
> >
> > Hi Eric, thanks for the updated patch.
> >
> > Overall, looks good to me, although I'd drop the "Exited." from the
> 1. How do you model round to +Inf (avg_floor) and round to -Inf (avg_ceil) ?
That's just specified by the +1 or the lack of it in the original pattern.
Actually the IFN is just a detour because we would create perfect code
if not for the fallback. But as there is currently now way to check for
Ping.
This is a very simple patch to correct a URL address in GCC13’s changes.html.
Currently, it’s pointing to a wrong address.
Okay for committing?
> On Jul 21, 2023, at 3:02 PM, Qing Zhao wrote:
>
> Hi,
>
> In the current GCC13 release note, the URL to the option -fstrict-flex-array
> is
Ping…
thanks.
Qing
> On Jul 10, 2023, at 3:11 PM, Qing Zhao wrote:
>
> Hi,
>
> This is the change for the GCC14 releaes Notes on the deprecating of a C
> extension about flexible array members.
>
> Okay for committing?
>
> thanks.
>
> Qing
>
>
>
> *htdocs/gcc-14/changes.html (Ca
Richard Biener writes:
> [...]
>> >> in vect_determine_precisions_from_range. Maybe we should drop
>> >> the shift handling from there and instead rely on
>> >> vect_determine_precisions_from_users, extending:
>> >>
>> >> if (TREE_CODE (shift) != INTEGER_CST
>> >> || !wi::ltu_p (wi::to_w
On Wed, 2023-08-02 at 14:46 -0400, Eric Feng wrote:
> On Wed, Aug 2, 2023 at 1:20 PM Marek Polacek
> wrote:
> >
> > On Wed, Aug 02, 2023 at 12:59:28PM -0400, David Malcolm wrote:
> > > On Wed, 2023-08-02 at 12:20 -0400, Eric Feng wrote:
> > >
[Dropping Joseph and Marek from the CC]
[...snip...
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 version of the patch.
> > > Instead of doing the matching
I just checked LLVM:
https://godbolt.org/z/nMa6qnEeT
This patch generally is reasonable so LGTM.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-08-03 02:49
To: 钟居哲; gcc-patches; palmer; kito.cheng; Jeff Law
CC: rdapp.gcc
Subject: Re: [PATCH] RISC-V: Implement vector "average" autovec patte
Plz put your testcases into:
# widening operation only test on LMUL < 8
set AUTOVEC_TEST_OPTS [list \
{-ftree-vectorize -O3 --param riscv-autovec-lmul=m1} \
{-ftree-vectorize -O3 --param riscv-autovec-lmul=m2} \
{-ftree-vectorize -O3 --param riscv-autovec-lmul=m4} \
{-ftree-vectorize -O2 -
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 patch is a conservative fix for PR target/110792, a wrong-code
regression affecting doubleword rotations by BITS_PER_WORD, which
effectively swaps the highpart and lowpart words, when the source to be
rotated resides in memory. The issue is that if the register used to
hold the lowpart of the
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
Committed, thanks Kito.
Pan
From: Kito Cheng
Sent: Wednesday, August 2, 2023 9:48 PM
To: Li, Pan2
Cc: GCC Patches ; 钟居哲 ; Wang,
Yanzhang
Subject: Re: [PATCH v1] RISC-V: Support RVV VFWSUB rounding mode intrinsic API
LGTM, thanks:)
Pan Li via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>> 於 2
From: Pan Li
This patch would like to support the rounding mode API for the VFMUL
for the below samples.
* __riscv_vfmul_vv_f32m1_rm
* __riscv_vfmul_vv_f32m1_rm_m
* __riscv_vfmul_vf_f32m1_rm
* __riscv_vfmul_vf_f32m1_rm_m
Signed-off-by: Pan Li
gcc/ChangeLog:
* config/riscv/riscv-vecto
extern const function_base *const vfmul;
-extern const function_base *const vfmul;
+extern const function_base *const vfmul_frm;
It seems that there is a redundant declaration in the original code?
extern const function_base *const vfmul;
-extern const function_base *const vfmul;
juzhe.zh...@r
Yes, looks there is some I missed after the last cleanup. I will have a double
check after rounding API support.
Pan
From: juzhe.zh...@rivai.ai
Sent: Thursday, August 3, 2023 9:40 AM
To: Li, Pan2 ; gcc-patches
Cc: Li, Pan2 ; Wang, Yanzhang ;
kito.cheng
Subject: Re: [PATCH v1] RISC-V: Support
Could you split it into 2 patches ?
one is cleanup patch which is removing the redundant declaration.
The other is support VFMUL API.
juzhe.zh...@rivai.ai
From: Li, Pan2
Date: 2023-08-03 09:44
To: juzhe.zh...@rivai.ai; gcc-patches
CC: Wang, Yanzhang; kito.cheng
Subject: RE: [PATCH v1] RISC-V
Sure thing, will prepare it on the double.
Pan
From: juzhe.zh...@rivai.ai
Sent: Thursday, August 3, 2023 10:02 AM
To: Li, Pan2 ; gcc-patches
Cc: Wang, Yanzhang ; kito.cheng
Subject: Re: RE: [PATCH v1] RISC-V: Support RVV VFMUL rounding mode intrinsic
API
Could you split it into 2 patches ?
From: Pan Li
This patch would like to remove the redudant declaration.
Signed-off-by: Pan Li
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.h: Remove
redudant declaration.
---
gcc/config/riscv/riscv-vector-builtins-bases.h | 1 -
1 file changed, 1 deletion(-)
diff
LGTM
於 2023年8月3日 週四 10:11 寫道：
> From: Pan Li
>
> This patch would like to remove the redudant declaration.
>
> Signed-off-by: Pan Li
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vector-builtins-bases.h: Remove
> redudant declaration.
> ---
> gcc/config/riscv/riscv-vector-builti
Committed, thanks Kito.
Pan
From: Kito Cheng
Sent: Thursday, August 3, 2023 10:12 AM
To: Li, Pan2
Cc: GCC Patches ; 钟居哲 ; Wang,
Yanzhang
Subject: Re: [PATCH v1] RISC-V: Remove redudant extern declaration in function
base
LGTM
mailto:pan2...@intel.com>> 於 2023年8月3日 週四 10:11 寫道：
From: Pan Li
1 - 100 of 126 matches
Mail list logo
