Hi Richard,
on 2024/7/8 19:14, Richard Sandiford wrote:
> "Kewen.Lin" writes:[snip...]
>>>
>>> This part looks good to me FWIW, but what's the correct behaviour of:
>>>
>>> if (GET_MODE_PRECISION (from_mode) == GET_MODE_PRECISION (to_mode))
>>> {
>>> if (REAL_MODE_FORMAT (to_mode)
Backported to gcc 14 already.
Pan
From: Li, Pan2
Sent: Wednesday, July 3, 2024 10:41 PM
To: Kito Cheng ; juzhe.zh...@rivai.ai
Cc: gcc-patches@gcc.gnu.org; jeffreya...@gmail.com; rdapp@gmail.com
Subject: RE: [PATCH v1] RISC-V: Bugfix vfmv insn honor zvfhmin for FP16 SEW
[PR115763]
Committed,
On 2024-07-09 01:49 Jeff Law wrote:
>
>
>
>On 7/8/24 2:39 AM, Fei Gao wrote:
>> Root cause:
>> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b27d323a368033f0b37e93c57a57a35fd9997864
>> Commit above tries in targetm.gen_epilogue () to detect if
>> there's li a0,0 insn at the end of insn chain, if
From: Pan Li
To get better vectorized code of .SAT_SUB, we would like to avoid the
truncated operation for the assignment. For example, as below.
unsigned int _1;
unsigned int _2;
unsigned short int _4;
_9 = (unsigned short int).SAT_SUB (_1, _2);
If we make sure that the _1 is in the range of
Forgot to say: either v2 or another patch are fine to me :)
On Tue, Jul 9, 2024 at 11:13 AM Kito Cheng wrote:
>
> Hi Edwin:
>
> Could you add B into riscv_combine_info as well? extension should list
> there if that extension is just an alias of those extensions, so that
> GCC will add b into arch
Hi Edwin:
Could you add B into riscv_combine_info as well? extension should list
there if that extension is just an alias of those extensions, so that
GCC will add b into arch string when zba, zbb, zbs, that's necessary
during arch string canonicalize, which could be used during multilib
match :)
LGTM, thanks :)
On Tue, Jul 9, 2024 at 10:47 AM Fei Gao wrote:
> According to Zc-1.0.4-3.pdf from
>
> https://github.com/riscvarchive/riscv-code-size-reduction/releases/tag/v1.0.4-3
> The rule is that:
> 1. C always implies Zca
> 2. C+F implies Zcf (RV32 only)
> 3. C+D implies Zcd
>
> gcc/Change
According to Zc-1.0.4-3.pdf from
https://github.com/riscvarchive/riscv-code-size-reduction/releases/tag/v1.0.4-3
The rule is that:
1. C always implies Zca
2. C+F implies Zcf (RV32 only)
3. C+D implies Zcd
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc:
c implies zca, and con
On 7/8/24 7:33 PM, Fei Gao wrote:
On 2024-07-09 01:49 Jeff Law wrote:
Has the ESWIN team ever considered doing a bootstrap test of the zcmp*
extensions? ie, turn them all on by default, then build GCC natively on
an rv32 system (or qemu emulated rv32 system)?
I've found that kind of test
On 2024-07-09 01:49 Jeff Law wrote:
>Has the ESWIN team ever considered doing a bootstrap test of the zcmp*
>extensions? ie, turn them all on by default, then build GCC natively on
>an rv32 system (or qemu emulated rv32 system)?
>
>I've found that kind of test amazingly helpful through the year
> What this means is is that you'll have to do the widening operations in
> the RISC-V expander. Essentially for an argument smaller than word_mode
> you'd want to widen to word_mode while retaining the right semantics.
Got it, I think it is the most different part between the scalar and vector
Thanks Jeff.
> Do we really need stdio.h? If not, let's avoid this hunk.
No, should be debug code, will remove it and commit the series.
Pan
-Original Message-
From: Jeff Law
Sent: Tuesday, July 9, 2024 1:34 AM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch..
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/14?
-- >8 --
When instantiating a previously declared hidden template friend declared
at class template scope such as slot_allocated in the first testcase below,
tsubst_friend_function needs to go through all existing
This is a minor cleanup I spotted whilst working on another patch.
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-1900-g113b5ce0610207.
gcc/c-family/ChangeLog:
* c-format.cc (format_check_results::format_check_results):
On Mon, 8 Jul 2024, Kyrylo Tkachov wrote:
>> How about the following simplification around generic-armv8-a and
>> generic-armv8-a? I believe this version is easier to consume.
> Yeah, that does look smoother.
> Ok. Thanks!
Pushed, thanks.
Gerald
On 3/1/24 12:48 AM, 钟居哲 wrote:
Hi, han. I understand you are trying to support optimize vector-
splat_vector into vector-scalar in "expand" stage, that is,
vv -> vx or vv -> vf.
It's a known issue that we know for a long time.
This patch is trying to transform vv->vf when the splat vector
On 6/11/24 4:39 AM, Andrew Burgess wrote:
Jeff,
Thanks for looking these patches over.
For testing, using current(ish) gcc HEAD, on x86-64 GNU/Linux, I:
../src/configure --prefix=$(cd .. && pwd)/install
make
make check
I did this with / without my patch and then:
find . -nam
On 6/30/24 6:47 PM, Vineet Gupta wrote:
Changes since v1:
- Removed UNSPEC_{INFINITE,ISNORMAL}
- Don't hardcode SI in patterns, try to keep X to avoid potential
sign extension pitfalls. Implementation wise requires skipping
:MODE specifier in match_operand which is flagged as m
On 7/3/24 8:07 PM, Li, Pan2 wrote:
But if you look at what the hardware can actually support, it doesn't
have HImode or QImode operations other than load/store and for rv64
there are no SImode logicals.
That's what WORD_REGISTER_OPERATIONS is designed to support. Regardless
of what happens
Promote HImode x86_movcc_0_m1_neg insn to SImode to avoid
redundant prefixes. Also promote QImode insn when TARGET_PROMOTE_QImode
is set. This is similar to promotable_binary_operator splitter, where we
promote the result to SImode.
Also correct insn condition for splitters to SImode of NEG and NO
On 7/8/24 1:25 PM, Patrick O'Neill wrote:
https://gcc.gnu.org/onlinedocs/gccint/Machine-Independent-Predicates.html
| Function: const_int_operand
| This predicate allows any CONST_INT expression that fits in mode.
It is an appropriate choice for an immediate operand that does not allow
On 7/8/24 3:37 PM, Iain Sandoe wrote:
Hello Jason,
before re-working, I think I need some guidance.
On 8 Jul 2024, at 20:19, Jason Merrill wrote:
On 6/17/24 8:15 AM, Iain Sandoe wrote:
This patch came out of a discussion on Mattermost about how to deal
with contracts/coroutines integration.
Hello Jason,
before re-working, I think I need some guidance.
> On 8 Jul 2024, at 20:19, Jason Merrill wrote:
>
> On 6/17/24 8:15 AM, Iain Sandoe wrote:
>> This patch came out of a discussion on Mattermost about how to deal
>> with contracts/coroutines integration. Actually, it would also allo
This fixes another problem with my recent changes to use memchr in
std::find.
Tested x86_64-linux.
-- >8 --
For an integer-class type we need to use an explicit conversion to size_t.
libstdc++-v3/ChangeLog:
PR libstdc++/115799
* include/bits/ranges_util.h (__find_fn): Make conv
Tested x86_64-linux. Pushed to trunk. This should be backported too.
-- >8 --
The definition of the _Atomic(T) macro needs to refer to ::std::atomic,
not some other std::atomic relative to the current namespace.
libstdc++-v3/ChangeLog:
PR libstdc++/115807
* include/c_compatibili
On 7/6/24 07:20, Jeff Law wrote:
On 7/3/24 3:16 PM, Patrick O'Neill wrote:
Regarding the amocas.q follow-up patch:
I'm having trouble with matching any TImode compare-and-swap
patterns. Here's the RTL I'm trying:
(define_mode_iterator SUPERGPR [SI DI TI])
(define_insn "zacas_atomic_cas_v
On 6/17/24 8:15 AM, Iain Sandoe wrote:
This patch came out of a discussion on Mattermost about how to deal
with contracts/coroutines integration. Actually, it would also allow
some semantic checking to be deferred until the same spot - at which
time there are no dependent types, which can simpli
Hi again!
It shouldn't be needed to build GDB separately or to specify the -m32 flags.
Not sure why you have to do that.
It was in the document you sent, especially some warning about
sh-elf-run not working on 64-bit hosts. Guess that's solved by now.
I've just tried the following configur
On 7/6/24 10:13 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
I have also been working on a patch that uses the locations of
using-decls in 'diagnose_name_conflict' and 'duplicate_decls' calls, but
that will need a fair bit more work that I'll probab
On 7/6/24 10:07 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This fixes an ICE exposed by supporting exported non-function
using-decls. Sometimes when preparing to define a class, xref_tag will
find a using-decl belonging to a different n
On 6/29/24 4:06 PM, Mark Harmstone wrote:
gcc/
* dwarf2codeview.cc (write_lf_modifier): Expand upon comment.
OK
jeff
On 6/29/24 4:06 PM, Mark Harmstone wrote:
CodeView symbols have to be multiples of four bytes; add an alignment
directive to write_data_symbol to ensure this.
Note that these can be zeroes, so we can rely on GAS to do this for us;
it's only types that need f3, f2, f1 values.
gcc/
On 6/29/24 4:06 PM, Mark Harmstone wrote:
Adds names for the padding magic numbers to enum cv_leaf_type.
gcc/
* dwarf2codeview.cc (enum cv_leaf_type): Add padding constants.
(write_cv_padding): Use names for padding constants.
OK
jeff
On 6/29/24 4:06 PM, Mark Harmstone wrote:
Make everything more gdb-friendly by using an enum for symbol constants
rather than #defines.
gcc/
* dwarf2codeview.cc (S_LDATA32, S_GDATA32, S_COMPILE3): Undefine.
(enum cv_sym_type): Define.
(struct codevi
On 6/29/24 4:06 PM, Mark Harmstone wrote:
Make everything more gdb-friendly by using an enum for type constants
rather than #defines.
gcc/
* dwarf2codeview.cc (enum cv_leaf_type): Define.
(struct codeview_subtype): Use enum cv_leaf_type.
(struct cod
On 7/8/24 2:39 AM, Fei Gao wrote:
Root cause:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b27d323a368033f0b37e93c57a57a35fd9997864
Commit above tries in targetm.gen_epilogue () to detect if
there's li a0,0 insn at the end of insn chain, if so, cm.popret
is replaced by cm.popretz and li a0,0
On 7/6/24 06:50, Jeff Law wrote:
On 7/2/24 7:28 PM, Patrick O'Neill wrote:
gcc/ChangeLog:
* doc/invoke.texi: Remove trailing whitespace.
OK
jeff
Committed.
Patrick
On 7/8/24 8:15 AM, pan2...@intel.com wrote:
From: Pan Li
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h: Add help
test macro.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_data.h: New test.
* gcc.target/riscv/rvv/autovec/binop/ve
On 7/8/24 11:20 AM, Edwin Lu wrote:
This patch adds support for recognizing the B standard extension to be the
collection of Zba, Zbb, Zbs extensions for consistency and conciseness across
toolchains
* https://github.com/riscv/riscv-b/tags
gcc/ChangeLog:
* common/config/riscv/riscv-
Update all instances of zba_zbb_zbs in the testsuite to use b instead.
gcc/testsuite/ChangeLog:
* g++.target/riscv/redundant-bitmap-1.C: Use gcb instead of
zba_zbb_zbs
* g++.target/riscv/redundant-bitmap-2.C: Ditto
* g++.target/riscv/redundant-bitmap-3.C: Ditto
This patch adds support for recognizing the B standard extension to be the
collection of Zba, Zbb, Zbs extensions for consistency and conciseness across
toolchains
* https://github.com/riscv/riscv-b/tags
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: Add imply rules for B
Support for recognizing B as the collection of zba, zbb, zbs extensions
https://github.com/riscv/riscv-b/tags
Edwin Lu (2):
RISC-V: Add support for B standard extension
RISC-V: Update testsuite to use b
gcc/testsuite/ChangeLog:
gcc/common/config/riscv/riscv-common.cc | 6
The musttail error messages are reported to the user, so must be
translated.
gcc/ChangeLog:
PR83324
* calls.cc (initialize_argument_information): Mark messages
for translation.
(can_implement_as_sibling_call_p): Dito.
(expand_call): Dito.
---
gcc/calls.cc
Implement a C23 clang compatible musttail attribute similar to the earlier
C++ implementation in the C parser.
PR83324
gcc/c/ChangeLog:
* c-parser.cc (struct attr_state): Define with musttail_p.
(c_parser_statement_after_labels): Handle [[musttail]]
(c_parser_std_
Some adopted from the existing C musttail plugin tests.
gcc/testsuite/ChangeLog:
* c-c++-common/musttail1.c: New test.
* c-c++-common/musttail2.c: New test.
* c-c++-common/musttail3.c: New test.
* c-c++-common/musttail4.c: New test.
* c-c++-common/musttail7
gcc/ChangeLog:
PR83324
* doc/extend.texi: Document [[musttail]]
---
gcc/doc/extend.texi | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index b2e41a581dd1..f83e643da19c 100644
--- a/gcc/doc/ex
When musttail is set, make tree-tailcall give error messages
when it cannot handle a call. This avoids vague "other reasons"
error messages later at expand time when it sees a musttail
function not marked tail call.
In various cases this requires delaying the error until
the call is discovered.
A
- Give error messages for all causes of non sibling call generation
- When giving error messages clear the musttail flag to avoid ICEs
- Error out when tree-tailcall failed to mark a must-tail call
sibcall. In this case it doesn't know the true reason and only gives
a vague message.
PR8332
Enable the tailcall optimization for non optimizing builds,
but in this case only checks calls that have the musttail attribute set.
This makes musttail work without optimization.
This is done with a new late musttail pass that is only active when
not optimizing. The new pass relies on tree-cfg to
This patch implements a clang compatible [[musttail]] attribute for
returns.
musttail is useful as an alternative to computed goto for interpreters.
With computed goto the interpreter function usually ends up very big
which causes problems with register allocation and other per function
optimizati
The actual handling is directly in the parser since the
generic mechanism doesn't support statement attributes,
but this gives basic error checking/detection on the attribute.
gcc/c-family/ChangeLog:
PR83324
* c-attribs.cc (handle_musttail_attribute): Add.
* c-common.h (ha
This version addresses all the review feedback (Thanks everyone!)
It is getting close to the finish line. The only missing reviews now
are for the C frontend part (patch 5). Joseph and Marek, I would
appreciate if you could take a look.
- Addressed Richie's feedback with various improvements
and
Some of the cfg fixups in pro_and_epilogue for sibcalls were dependent on
"optimize".
Make them check cfun->tail_call_marked instead to handle the -O0 musttail
case. This fixes the musttail test cases on arm targets.
gcc/ChangeLog:
PR target/115255
* function.cc (thread_prologue_
Hi there,
Checking in to see if you received my previous email. Could we move forward
with sharing sample leads?
Best,
Brenda
___
Fr
On 7/8/24 6:58 AM, Manolis Tsamis wrote:
This is still hard to tell. In some cases I have observed either
improvement or regressions in benchmarks, which are highly susceptible
to costing and the specific store-forwarding penalties of the CPU.
I have seen cases where the store-forwarding ins
On 7/6/24 10:06 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
With modules, a non-function using-declaration is not completely
interchangable with the declaration that it refers to; in particular,
such a using-declaration may be exported wi
On 7/7/24 11:29 PM, Fei Gao wrote:
On 2024-07-06 22:15 Jeff Law wrote:
On 7/5/24 3:56 AM, Fei Gao wrote:
According to Zc-1.0.4-3.pdf from
https://github.com/riscvarchive/riscv-code-size-reduction/releases/tag/v1.0.4-3
The rule is that:
1. C always implies Zca
2. C+F implies Zcf (RV32 on
This patch makes the non-predicated vdupq_n MVE intrinsics use
vec_duplicate rather than an unspec. This enables the compiler to
generate better code sequences (for instance using vmov when
possible).
The patch renames the existing mve_vdup pattern into
@mve_vdupq_n, and removes the now useless
@
This patch fixes a bug where the mode iterator for mve_vdup
should be MVE_VLD_ST instead of MVE_vecs: V2DI and V2DF (thus vdup.64)
are not supported by MVE.
2024-07-02 Jolen Li
Christophe Lyon
gcc/
* config/arm/mve.md (mve_vdup): Fix mode iterator.
---
gcc/config
On Mon, Jul 08, 2024 at 05:27:53PM +0200, Richard Biener wrote:
>
>
> > Am 08.07.2024 um 17:22 schrieb Andi Kleen :
> >
> > On Mon, Jul 08, 2024 at 08:53:27AM +0200, Richard Biener wrote:
> >> Ah, I see. So this pass is responsible for both -O0 and
> >> -fno-optimized-sibling-calls.
> >> But I
> I have added a target hook for this in v4 of this patch. The hook
> receives all the information about the stores, the load, the estimated
> sequence cost and whether we expect to eliminate the load. With this
> information the target should be able to make an informed decision.
>
> What you men
On Mon, Jul 08, 2024 at 09:06:21AM +0200, Richard Biener wrote:
> On Sat, Jul 6, 2024 at 8:45 PM Andi Kleen wrote:
> >
> > > >if (!single_succ_p (bb))
> > > > -return;
> > > > +{
> > > > + int num_eh, num_other;
> > > > + bb_get_succ_edge_count (bb, num_eh, num_other);
> > >
> Am 08.07.2024 um 17:22 schrieb Andi Kleen :
>
> On Mon, Jul 08, 2024 at 08:53:27AM +0200, Richard Biener wrote:
>> Ah, I see. So this pass is responsible for both -O0 and
>> -fno-optimized-sibling-calls.
>> But I'm quite sure the other pass doesn't run with -O0
>> -foptimize-sibling-calls,
> > Overall the logic in this pass is rather convoluted and
> > could deserve some cleanups and separation of concerns.
> > e.g. it would be better to separate tail calls and tail
> > recursion. But I'm not trying to rewrite the pass here.
>
> Understood. For a v9, can you squash the tree-tailcal
On Mon, Jul 08, 2024 at 08:53:27AM +0200, Richard Biener wrote:
> Ah, I see. So this pass is responsible for both -O0 and
> -fno-optimized-sibling-calls.
> But I'm quite sure the other pass doesn't run with -O0
> -foptimize-sibling-calls, does it?
It does run:
./cc1 -O0 -fdump-passes -foptimize-
On Mon, 8 Jul 2024, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/14?
>
> -- >8 --
>
> When duplicate_decls finds a match with an existing imported
> declaration, it clears DECL_LANG_SPECIFIC of the olddecl and replaces it
> with the contents of newdecl
Hi,
I'm replying to Richard and keeping Andrew in cc since your suggestions
overlap.
On Tue 2024-06-11 14:48:06, Richard Biener wrote:
> On Thu, 30 May 2024, Filip Kastl wrote:
> > +/* { dg-do compile } */
> > +/* { dg-options "-O2 -fdump-tree-switchconv -march=znver3" } */
>
> I think it's bet
On 7/8/24 7:47 AM, Nina Dinka Ranns wrote:
HI Jason,
On Fri, 5 Jul 2024 at 17:31, Jason Merrill wrote:
On 7/5/24 10:25 AM, Nina Dinka Ranns wrote:
Certain places in contract parsing currently do not check for errors.
This results in contracts
with embedded errors which eventually confuse gim
> Am 08.07.2024 um 16:39 schrieb Eric Botcazou :
>
>
>>
>> IIRC at least some array of vector also have vector mode, I'm not sure
>> type_for_mode is an INTEGER_TYPE in that case nor am I sure the max 128
>> bytes size holds here.
>
> Yes, array types may have vector modes.
>
>> There's al
> IIRC at least some array of vector also have vector mode, I'm not sure
> type_for_mode is an INTEGER_TYPE in that case nor am I sure the max 128
> bytes size holds here.
Yes, array types may have vector modes.
> There's also array_mode_supported_p which can indicate larger modes are OK.
Yes, b
Thanks Richard for comments.
> Sorry if this has been asked before, but: why not use SAT_TRUNC
> instead of MIN_EXPR+truncate?
Oops, the .SAT_TRUNC is not ready when draft this patch. Yes, we can leverage
SAT_TRUNC now as .SAT_TRUNC committed, will update in v3.
> I was suggesting to only rely
From: Pan Li
After the middle-end supported the vector mode of .SAT_ADD, add more
testcases to ensure the correctness of RISC-V backend for form 1. Aka:
Form 1:
#define DEF_VEC_SAT_U_ADD_IMM_FMT_1(T, IMM) \
T __attribute__((noinline))
From: Pan Li
After the middle-end supported the vector mode of .SAT_ADD, add more
testcases to ensure the correctness of RISC-V backend for form 2. Aka:
Form 2:
#define DEF_VEC_SAT_U_ADD_IMM_FMT_2(T, IMM) \
T __attribute__((noinline))
On 7/8/24 5:52 AM, Oleg Endo wrote:
From what I know it started during the earlier cygwin days in the 90s,
originally contracted by Hitachi to complement their own in-house C compiler
and also to allow sh-linux to happen at some point. It was entertained by
Renesas for a while through furt
The following adds support for group-size three in SLP load permutation
lowering to match the non-SLP capabilities. This is done by using
the non-interleaving fallback code which then creates at VF == 4 from
{ { a0, b0, c0 }, { a1, b1, c1 }, { a2, b2, c2 }, { a3, b3, c3 } }
the intermediate vector
The following emulates classical interleaving for SLP load permutes
that we are unlikely handling natively. This is to handle cases
where interleaving (or load/store-lanes) is the optimal choice for
vectorizing even when we are doing that within SLP. An example
would be
void foo (int * __restric
On Thu, Jun 13, 2024 at 7:18 PM Andi Kleen wrote:
>
> Manolis Tsamis writes:
> >
> > Assembly like this can appear with bitfields or type punning / unions.
> > On stress-ng when running the cpu-union microbenchmark the following
> > speedups
> > have been observed.
> >
> > Neoverse-N1: +2
This pass detects cases of expensive store forwarding and tries to avoid them
by reordering the stores and using suitable bit insertion sequences.
For example it can transform this:
strbw2, [x1, 1]
ldr x0, [x1] # Expensive store forwarding to larger load.
To:
ldr
Hello friend,
Hope this email finds you well!
This is *Amy* from WellSucceed Embroidery, a company with 21years
experience in branding apparel & accessories.
Our products cover every corner in life. From soft to hard and small to
big, such as plush toys, backpacks, knit sweaters, underwear, be
Bootstrapped and regtested (so far just modules.exp) on
x86_64-pc-linux-gnu, OK for trunk/14 if full regtest succeeds?
-- >8 --
When importing modules, when a binding vector for a name runs out of
slots it gets reallocated with a larger size, and existing bindings are
copied across. However, the
Hi,
> > > > The default sh-elf configuration has no multi-libs for SH3 and SH4
> > > > variants
> > > > without FPU (from what I can see). So it won't use soft-fp so much
> > > > during
> > > > sim testing. So please change to soft-fp for sh*, not just SH3/SH4.
> >
> > Got it, done that loc
HI Jason,
On Fri, 5 Jul 2024 at 17:31, Jason Merrill wrote:
>
> On 7/5/24 10:25 AM, Nina Dinka Ranns wrote:
> > Certain places in contract parsing currently do not check for errors.
> > This results in contracts
> > with embedded errors which eventually confuse gimplify. Checks for
> > errors add
On Fri, Jul 5, 2024 at 4:20 PM wrote:
>
> From: Pan Li
>
> To get better vectorized code of .SAT_SUB, we would like to avoid the
> truncated operation for the assignment. For example, as below.
>
> unsigned int _1;
> unsigned int _2;
> _9 = (unsigned short int).SAT_SUB (_1, _2);
>
> If we make
pan2...@intel.com writes:
> From: Pan Li
>
> To get better vectorized code of .SAT_SUB, we would like to avoid the
> truncated operation for the assignment. For example, as below.
>
> unsigned int _1;
> unsigned int _2;
> _9 = (unsigned short int).SAT_SUB (_1, _2);
>
> If we make sure that the _
The following is a prototype for how to represent load/store-lanes
within SLP. I've for now settled with having a single load node
with multiple permute nodes, one for each loaded lane and a single
store node plus a single permute node feeding it. For
for (int i = 0; i < 1024; ++i)
{
On Mon, Jul 8, 2024 at 11:27 AM Tejas Belagod wrote:
>
> Hi,
>
> Sorry to have dropped the ball on
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625535.html, but
> here I've tried to pick it up again and write up a strawman proposal for
> elevating __attribute__((vector_mask)) to the FE fr
"Kewen.Lin" writes:
> Hi Richard,
>
> Thanks for the review comments!
>
> on 2024/7/4 23:58, Richard Sandiford wrote:
>> "Kewen.Lin" writes:
>>> Hi,
>>>
>>> With some historical reasons, rs6000 defines KFmode, TFmode
>>> and IFmode to have different mode precision, but it causes
>>> some issues a
Ping^2 on the series please.
Thanks,
Tejas.
On 5/27/24 10:36 AM, Tejas Belagod wrote:
Note: This patch series is based on Richard's initial patch
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606741.html
and Jakub's suggestion
https://gcc.gnu.org/pipermail/gcc-patches/2023-Febru
Hi,
Sorry to have dropped the ball on
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625535.html, but
here I've tried to pick it up again and write up a strawman proposal for
elevating __attribute__((vector_mask)) to the FE from GIMPLE.
Thanks,
Tejas.
Motivation
--
The idea o
ping
чт, 20 июн. 2024 г. в 12:09, Siarhei Volkau :
>
> This patch deals with consequences but not the root cause though.
>
> There are 5 cases which are subjects to rewrite:
> case #1:
> mov ip, r1
> add r2, ip
> # ip is dead here
> can be rewritten as:
> adds r2, r1
>
> case #2:
> add i
Root cause:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b27d323a368033f0b37e93c57a57a35fd9997864
Commit above tries in targetm.gen_epilogue () to detect if
there's li a0,0 insn at the end of insn chain, if so, cm.popret
is replaced by cm.popretz and li a0,0 insn is deleted.
Insertion of the gene
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-07-08 14:57
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li
Subject: [PATCH v3] RISC-V: Implement .SAT_TRUNC for vector unsigned int
From: Pan Li
This patch would like to implement the .SAT_TRUNC for the RISC-V
b
On Mon, Jul 8, 2024 at 9:11 AM Eric Botcazou wrote:
>
> Hi,
>
> the Ada compiler now defers to the gimplifier for ordering comparisons of
> arrays of bytes (Ada parlance for <, >, <= and >=) because the gimplifier in
> turn defers to memcmp for them, which implements the required semantics.
>
> Ho
Hi Gerald,
> On 7 Jul 2024, at 19:26, Gerald Pfeifer wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Tue, 2 Apr 2024, Kyrylo Tkachov wrote:
>> Here's a writeup of the AArch64 changes to highlight in GCC 14.1. If
>> there's something you'd like to highlight feel fre
Hi,
the Ada compiler now defers to the gimplifier for ordering comparisons of
arrays of bytes (Ada parlance for <, >, <= and >=) because the gimplifier in
turn defers to memcmp for them, which implements the required semantics.
However the gimplifier has a special processing for aggregate types
On Sat, Jul 6, 2024 at 8:45 PM Andi Kleen wrote:
>
> > >if (!single_succ_p (bb))
> > > -return;
> > > +{
> > > + int num_eh, num_other;
> > > + bb_get_succ_edge_count (bb, num_eh, num_other);
> > > + /* Allow EH edges so that we can give a better
> > > +error mes
96 matches
Mail list logo
