Add missing Runtime Library Exception to mve header files to bring them
into line with other similar headers. Not adding it in the first place
was an oversight.
gcc/ChangeLog:
* config/arm/arm_mve.h: Add Runtime Library Exception.
* config/arm/arm_mve_types.h: Likewise.diff --g
Hi Christophe,
On 28/11/2024 17:00, Christophe Lyon wrote:
Hi Andre,
Thanks, the patch LGTM except a minor nit:
/* Using a VPR that gets re-generated within the loop. */
-void test10 (int32_t *a, int32_t *b, int32_t *c, int n)
+void test10a (int32_t *a, int32_t *b, int32_t *c, int n)
[...]
Hi Christophe,
On 28/11/2024 10:22, Christophe Lyon wrote:
The VCTP instruction creates a Vector Tail Predicate in VPR.P0, based
on the input value, but also constrained by a VPT block (if present),
or if used within a DLSTP/LETP loop.
Therefore we need to inform the compiler that this intrinsi
Hi,
Looks like single_pred ICEs if the basic-block does not have a single
predecessor rather than return NULL, which was what this snippet of code
relied on.
This feels like borderline obvious to me as a fix, but I thought I'd get
it checked by one more person.
Call 'single_pred_p' before 's
On 31/10/2024 08:23, Alexandre Oliva wrote:
On Oct 25, 2024, "Andre Vieira (lists)" wrote:
I have to admit I am not super familiar with long doubles, either than
knowing they are 128-bit FP representations... but bisect has pointed
me to this patch when investigating a reg
On 08/10/2024 17:18, Richard Sandiford wrote:
Andrew Carlotti writes:
This includes +fcma as a dependency of +sve, and means that we can
finally support fcma intrinsics on a64fx.
Also add fcma to the Features list in several cpunative testcases that
incorrectly included sve without fcma.
g
Hey,
I have to admit I am not super familiar with long doubles, either than
knowing they are 128-bit FP representations... but bisect has pointed me
to this patch when investigating a regression on aarch64_be-none-elf for
the libstdc++ testcase: 26_numerics/complex/13450.cc
After some reduct
Sorry for the delay, some other work popped up in between and this had
some latent issues. They should all be addressed now in this new patch.
When not dealing with the special armv8.1-m.main conditional
instructions case make sure it uses the
default_noce_conversion_profitable_p call to dete
Hi,
This looks like an acceptable work around. We special case behavior that
I'm not sure we can express in ways GCC can understand or will make use
of, whilst at the same time we keep expressing behavior it does
understand and can optimize.
Nice idea!
LGTM, needs maintainer approval though
Hi,
This patch fixes constant folding of BIT_INSER_EXPR for BYTES_BIG_ENDIAN
targets.
Regression tested on aarch64be-none-elf.
Almost committed this as obvious, but I wanted to double check the
testcase with a maintainer. I decided to not make the test be big-endian
specific, nor to add any
Committed attached patch as obvious.
This obvious patch fixes two warnings introduced with the implementation
of arm_noce_conversion_profitable_p hook.
gcc/ChangeLog:
* config/arm/arm.cc (arm_noce_oncersion_profitable_p): Remove unused
argument name.
(arm_is_v81m_cond_
On 07/10/2024 10:15, Christophe Lyon wrote:
On Mon, 7 Oct 2024 at 11:04, Torbjorn SVENSSON
wrote:
On 2024-10-07 10:53, Andre Vieira (lists) wrote:
Hi Torbjorn,
2. All other the test cases in the list above: These need to be
adapted to the change introduced in r15-3606-g7d6c6a0d15c to
Hi Torbjorn,
On 07/10/2024 09:08, Torbjorn SVENSSON wrote:
There are 3 test cases that are fixed with these 2 commits, but there is
also a bunch that is marked as new fails.
Looking at the test cases that fail, there are 2 different kinds of
failures.
1. gcc.target/arm/attr_thumb.c: This
Hi,
The patch for 'arm: Fix missed CE optimization for armv8.1-m.main [PR
116444]' introduced regressions with arm targets that used 'noce' before.
This is because it would approve all noce optimisations without using
the default cost check. Not sure why this didn't show up in my original
test
Resending as v2 so CI picks it up.
This patch refactors and fixes an issue where
arm_mve_dlstp_check_dec_counter
was making an assumption about the form of what a candidate for a dec_insn.
This dec_insn is the instruction that decreases the loop counter inside a
decrementing loop and we expect it
On 26/09/2024 18:56, Ramana Radhakrishnan wrote:
+/* Helper function to determine whether SEQ represents a sequence of
+ instructions representing the Armv8.1-M Mainline conditional arithmetic
+ instructions: csinc, csneg and csinv. The cinc instruction is generated
+ using a diffe
Hi,
This patch restores missed optimizations for armv8.1-m.main targets that
were missed when the generation of csinc, csinv and csneg were enabled
or the same with patch series containing:
commit c2bb84be4a6e581bbf45891457ee632a07416982
Author: Sudi Das
Date: Fri Sep 18 15:47:46 2020 +010
Hi,
The 'code' part of a 'define_code_attr' refers to the type of the key,
in other words, it uses a code_iterator to pick the value from their
(key "value") pair list.
Though it seems rtx_alloc_for_name requires a code_attribute to be used
when the 'value' needs to be a type. In other words,
I'm not a maintainer but I'd argue the entire test is bogus.
The error reporting in this area seems to be somewhat fragile, if you
compile it with '-march=armv7-a -mfloat-abi=soft', you also don't get
the error this is testing for. I'd argue this kind of user friendly
error message should jus
On 11/07/2024 22:42, Christophe Lyon wrote:
+ bool
+ check (function_checker &c) const override
+ {
+if (c.mode_suffix_id == MODE_none)
+ return true;
+
+unsigned int bits = c.type_suffix (0).element_bits;
+return c.require_immediate_range (1, 1, bits);
+ }
When trying t
Hi,
This looks great to me, only one small suggestion, but take it or leave
it I think it's a matter of preference.
On 11/07/2024 22:42, Christophe Lyon wrote:
+ /* No predicate, no suffix. */
if (e.type_suffix (0).integer_p)
if (e.type_suffix (0).unsigne
Hi Christophe,
Maybe this patch was based on an older source, but the comment now reads:
/* _t vfoo[t0](_t, _t)
_t vfoo[_n_t0](_t, _t)
Where the _n form only supports s16/s32/u16/u32 types as for vorrq.
Example: vorrq.
int16x8_t [__arm_]vorrq[_s16](int16x8_t a, int16x8_t b)
int1
Yeah true... committed.
On 01/08/2024 13:54, Christophe Lyon wrote:
On 8/1/24 12:02, Andre Vieira (lists) wrote:
On 01/08/2024 10:09, Christophe Lyon wrote:
It seems your attachment contains only the commit message but lacks
the actual patch?
I blame lack of coffee...
Thanks.
The
On 01/08/2024 10:09, Christophe Lyon wrote:
It seems your attachment contains only the commit message but lacks the
actual patch?
I blame lack of coffee...
Thanks.diff --git a/gcc/testsuite/gcc.target/arm/mve/ivopts-3.c
b/gcc/testsuite/gcc.target/arm/mve/ivopts-3.c
index
19b2442ef12cbf
Hi,
This patch ensures this testcase is ran for armv8.1-m.main+mve as this
is testing that doloops with function calls that aren't intrinsics get
rejected as potential doloop targets during ivopts. For other targets
this loop gets rejected for different reasons.
gcc/testsuite/ChangeLog:
This patch refactors and fixes an issue where
arm_mve_dlstp_check_dec_counter
was making an assumption about the form of what a candidate for a
dec_insn
should be, which caused an ICE.
This dec_insn is the instruction that decreases the loop counter
inside a
decrementing loop a
Hi Christophe,
Thanks for the comments, attached new version for testcase, see below
new cover letter:
This patch refactors and fixes an issue where
arm_mve_dlstp_check_dec_counter
was making an assumption about the form of what a candidate for a dec_insn.
This dec_insn is the instruction th
This patch refactors and fixes an issue where
arm_mve_dlstp_check_dec_counter
was making an assumption about the form of what a candidate for a dec_insn.
It also makes sure that if it does not initially encounter a 'set' in such a
form it tries to find another set that could be the right one.
Looks like I forgot to CC you Richard. But yeh ping :)
On 26/06/2024 13:20, Andre Vieira (lists) wrote:
This patch fixes the backend pattern that was printing the wrong input
scalar register pair when inserting into lane 1.
Added a new test to force float-abi=hard so we can use scan-assembler
This patch fixes the backend pattern that was printing the wrong input
scalar register pair when inserting into lane 1.
Added a new test to force float-abi=hard so we can use scan-assembler to
check
correct codegen.
Regression tested arm-none-eabi with
-march=armv8.1-m.main+mve/-mfloat-abi=ha
Hi,
With the introduction of low overhead loops in
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3dfc28dbbd21b1d708aa40064380ef4c42c994d7
we defined arm_predict_doloop_p, this is meant to be a low-weight check
to rule out loops we are not considering for doloop optimization and it
is used by
On 06/06/2024 12:53, Richard Earnshaw (lists) wrote:
On 05/06/2024 17:07, Andre Vieira (lists) wrote:
Hi,
This patch adds missing assembly directives to the CMSE library wrapper to call
functions with attribute cmse_nonsecure_call. Without the .type directive the
linker will fail to
On 11/06/2024 14:59, Richard Earnshaw (lists) wrote:
You effectively have an 'else if' split across a comment here, and the
indentation looks weird. Either write 'else if' on one line (and re-indent
accordingly) or put this entire block inside braces.
Apologies here, Torbjorn had this as
Hi,
So, you talk about gen_thumb1_extendhisi2, but there is also
gen_thumb1_extendqisi2. Will it actually be cleaner if the block is
indented one level?
The comment can be added in the "if (TARGET_THUMB1)" block regardless to
indicate that gen_rtx_SIGN_EXTEND can't be used.
gen_rtx_SIGN_EX
Hi Torbjorn,
Thanks for this, I have some comments below.
On 07/06/2024 09:56, Torbjörn SVENSSON wrote:
Properly handle zero and sign extension for Armv8-M.baseline as
Cortex-M23 can have the security extension active.
Currently, there is a internal compiler error on Cortex-M23 for the
epilog p
Hi,
This patch adds missing assembly directives to the CMSE library wrapper
to call functions with attribute cmse_nonsecure_call. Without the .type
directive the linker will fail to produce the correct veneer if a call
to this wrapper function is to far from the wrapper itself. The .size
wa
On 04/06/2024 12:50, Richard Biener wrote:
On Tue, 4 Jun 2024, Andre Vieira (lists) wrote:
Hi,
We got a question as to whether GCC had something similar to llvm's pragma
clang loop interleave_count(N), see
https://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop
Hi,
We got a question as to whether GCC had something similar to llvm's
pragma clang loop interleave_count(N), see
https://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations
I did a quick hack, using 'GCC interleaves N', just as a proof of
concept, to see wheth
Hey Jakub,
This what ya had in mind?
Kind regards,
Andre Vieiradiff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index
ca5174de991bb088f653468f77485c15a61526e6..924e045a15a78b5702a0d6997953f35c6b47efd1
100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
This patch fixes some testisms introduced by:
commit 5aa3fec38cc6f52285168b161bab1a869d864b44
Author: Andre Vieira
Date: Wed Apr 10 16:29:46 2024 +0100
aarch64: Add support for _BitInt
The testcases were relying on an unnecessary sign-extend that is no longer
generated.
The tested versi
Hi,
Patch to add AArch64 to the list of supported _BitInt(N) in
gcc-14/changes.html.
OK?diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index
a7ba957110183f906938d935bfa17aaed2ba20c8..55ab8c14c6d0b54e05a5f266f25c8ef1a4f959bf
100644
--- a/htdocs/gcc-14/changes.html
+++ b/
Added the target check, also had to change some of the assembly checking
due to changes upstream, the assembly is still valid, but we do extend
where not necessary, I do believe that's a general issue though.
The _BitInt(N > 64) codegen for non-powers of 2 did get worse, we see
similar codegen
regards,
Andre
On 28/03/2024 12:54, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
This patch makes sure we do not give ABI change diagnostics for the ABI
breaks of GCC 9, 13 and 14 for any type involving _BitInt(N), since that
type did not exist before this GCC version.
This patch adds support for C23's _BitInt for the AArch64 port when
compiling for little endianness. Big Endianness requires further
target-agnostic support and we therefor disable it for now.
The tests expose some suboptimal codegen for which I'll create PR's for
optimizations after this goe
This patch makes sure we do not give ABI change diagnostics for the ABI
breaks of GCC 9, 13 and 14 for any type involving _BitInt(N), since that
type did not exist before this GCC version.
ChangeLog:
* config/aarch64/aarch64.cc (bitint_or_aggr_of_bitint_p): New function.
(aarch
Hi,
Introduced a new patch to disable diagnostics for ABI breaks involving
_BitInt(N) given the type didn't exist, let me know what you think of that.
Also added further testing to replicate the ABI diagnostic tests to use
_BitInt(N).
Andre Vieira (2)
aarch64: Do not give ABI change diagnos
Hi,
After the backport off PR target/112787 a failure was reported against
x86_64, this would be fixed by backporting:
* tree-optimization/91838 - fix FAIL of g++.dg/opt/pr91838.C
(d1c072a1c3411a6fe29900750b38210af8451eeb)
* tree-optimization/110838 - less aggressively fold out-of-bound shifts
Hi Thiago,
Thanks for this, LGTM but I can't approve this, CC'ing Richard.
Do have a nitpick, in the gcc/testsuite/ChangeLog: remove
'gcc/testsuite' from bullet points 2-4.
Kind regards,
Andre
On 13/01/2024 00:55, Thiago Jung Bauermann wrote:
Since commits 2c3db94d9fd ("c: Turn int-conversi
Hi,
Bootstrapped and tested the gcc-13 backport of this on gcc-12 for
aarch64-unknown-linux-gnu and x86_64-pc-linux-gnu and no regressions.
OK to push to gcc-12 branch?
Kind regards,
Andre Vieira
On 10/11/2023 13:16, Richard Biener wrote:
The following fixes the issue that when SLP stmts ar
On 27/02/2024 08:47, Richard Biener wrote:
On Mon, 26 Feb 2024, Andre Vieira (lists) wrote:
On 05/02/2024 09:56, Richard Biener wrote:
On Thu, 1 Feb 2024, Andre Vieira (lists) wrote:
On 01/02/2024 07:19, Richard Biener wrote:
On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
The
Hey,
Dropped the first patch and dealt with the comments above, hopefully I
didn't miss any this time.
--
This patch adds support for C23's _BitInt for the AArch64 port when
compiling
for little endianness. Big Endianness requires further target-agnostic
sup
On 05/02/2024 09:56, Richard Biener wrote:
On Thu, 1 Feb 2024, Andre Vieira (lists) wrote:
On 01/02/2024 07:19, Richard Biener wrote:
On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
The patch didn't come with a testcase so it's really hard to tell
what goes wrong now and
On 19/02/2024 16:17, Jakub Jelinek wrote:
On Mon, Feb 19, 2024 at 04:13:29PM +, Andre Vieira (lists) wrote:
Replaced uses of __seg_gs with the MACRO SEG defined in the testcase to pick
(if any) the right __seg_{gs,fs} keyword based on target.
gcc/testsuite/ChangeLog:
* gcc.dg
Replaced uses of __seg_gs with the MACRO SEG defined in the testcase to
pick (if any) the right __seg_{gs,fs} keyword based on target.
gcc/testsuite/ChangeLog:
* gcc.dg/bitint-86.c (__seg_gs): Replace with SEG MACRO.diff --git a/gcc/testsuite/gcc.dg/bitint-86.c b/gcc/testsuite/gcc.dg/bi
Regards,
Andre
On 20/12/2023 14:30, Richard Biener wrote:
On Wed, 20 Dec 2023, Andre Vieira (lists) wrote:
Thanks, fully agree with all comments.
gcc/ChangeLog:
PR target/112787
* tree-vect-generic (type_for_widest_vector_mode): Change function
to use original vector
On 01/02/2024 07:19, Richard Biener wrote:
On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
The patch didn't come with a testcase so it's really hard to tell
what goes wrong now and how it is fixed ...
My bad! I had a testcase locally but never added it...
However... now I look
On 31/01/2024 14:35, Richard Biener wrote:
On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
On 31/01/2024 13:58, Richard Biener wrote:
On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
On 31/01/2024 12:13, Richard Biener wrote:
On Wed, 31 Jan 2024, Richard Biener wrote:
On Tue, 30
On 31/01/2024 14:03, Richard Biener wrote:
On Wed, 31 Jan 2024, Richard Biener wrote:
On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
On 31/01/2024 12:13, Richard Biener wrote:
On Wed, 31 Jan 2024, Richard Biener wrote:
On Tue, 30 Jan 2024, Andre Vieira wrote:
This patch adds
On 31/01/2024 13:58, Richard Biener wrote:
On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
On 31/01/2024 12:13, Richard Biener wrote:
On Wed, 31 Jan 2024, Richard Biener wrote:
On Tue, 30 Jan 2024, Andre Vieira wrote:
This patch adds stmt_vec_info to TARGET_SIMD_CLONE_USABLE to
On 31/01/2024 12:13, Richard Biener wrote:
On Wed, 31 Jan 2024, Richard Biener wrote:
On Tue, 30 Jan 2024, Andre Vieira wrote:
This patch adds stmt_vec_info to TARGET_SIMD_CLONE_USABLE to make sure the
target can reject a simd_clone based on the vector mode it is using.
This is needed bec
Hi,
This patch is still work in progress, but posting to show failure with
bitint-7 test where handle_stmt called from lower_mergeable_stmt ICE's
because the idx (3) is out of range for the __BitInt(135) with a
limb_prec of 64.
I hacked gcc locally to work around this issue and still have on
Squashed the definition and changes to predicated_doloop_end_internal
and dlstp*_insn into this patch to make sure the first patch builds
independently
On 18/12/2023 11:53, Andre Vieira wrote:
Reworked Stam's patch after comments in:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640
Reworked patch after Richard's comments and moved
predicated_doloop_end_internal and dlstp*_insn to the next patch in the
series to make sure this one builds on its own.
On 18/12/2023 11:53, Andre Vieira wrote:
Re-sending Stam's first patch, same as:
https://gcc.gnu.org/pipermail/gcc-patches/
This patch fixes an issue introduced by:
commit ea4a3d08f11a59319df7b750a955ac613a3f438a
Author: Andre Vieira
Date: Wed Nov 1 17:02:41 2023 +
omp: Reorder call for TARGET_SIMD_CLONE_ADJUST
The problem was that after this patch we no longer added multiple
arguments for vector argument
): Pass original vector type rather than the element
type to type_for_widest_vector_mode and remove now obsolete check
for the number of elements.
On 07/12/2023 07:45, Richard Biener wrote:
On Wed, 6 Dec 2023, Andre Vieira (lists) wrote:
Hi,
This patch addresses the issue
On 13/12/2023 10:55, Jakub Jelinek wrote:
On Wed, Dec 13, 2023 at 10:43:16AM +, Andre Vieira (lists) wrote:
Hi,
Apologies for the delay and this mixup. I need to do something different
This is to fix testisms initially introduced by:
commit f5fc001a84a7dbb942a6252b3162dd38b4aae311
Hi,
Apologies for the delay and this mixup. I need to do something different
This is to fix testisms initially introduced by:
commit f5fc001a84a7dbb942a6252b3162dd38b4aae311
Author: Andre Vieira
Date: Mon Dec 11 14:24:41 2023 +
aarch64: enable mixed-types for aarch64 simdclones
gcc/
On 11/12/2023 21:42, Thomas Schwinge wrote:
Hi Andre!
On 2023-10-16T16:03:26+0100, "Andre Vieira (lists)"
wrote:
Just a minor update to the patch, I had missed the libgomp testsuite, so
had to make some adjustments there too.
Unfortunately, there appear to be a number
comments, see latest revision attached.
On 27/11/2023 12:47, Andre Vieira (lists) wrote:
Hi Stam,
Just some comments.
+/* Recursively scan through the DF chain backwards within the basic
block and
+ determine if any of the USEs of the original insn (or the USEs of
the insns
s/Recursively scan
Hi,
This patch addresses the issue reported in PR target/112787 by improving the
compute type selection. We do this by not considering types with more
elements
than the type we are lowering since we'd reject such types anyway.
gcc/ChangeLog:
PR target/112787
* tree-vect-gener
On 29/11/2023 17:01, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
Rebased, no major changes, still needs review.
On 30/08/2023 10:19, Andre Vieira (lists) via Gcc-patches wrote:
This patch finalizes adding support for the generation of SVE simd
clones when no
On 06/11/2023 07:52, Richard Biener wrote:
On Fri, 3 Nov 2023, Andre Vieira (lists) wrote:
Hi,
The current codegen code to support VF's that are multiples of a simdclone
simdlen rely on BIT_FIELD_REF to create multiple input vectors. This does not
work for non-constant simdclones,
Hi Stam,
Just some comments.
+/* Recursively scan through the DF chain backwards within the basic
block and
+ determine if any of the USEs of the original insn (or the USEs of
the insns
s/Recursively scan/Scan/ as you no longer recurse, thanks for that by
the way :) + where thy were DEF-e
Hi,
The current codegen code to support VF's that are multiples of a
simdclone simdlen rely on BIT_FIELD_REF to create multiple input
vectors. This does not work for non-constant simdclones, so we should
disable using such clones when
the VF is a multiple of the non-constant simdlen until we
On 03/11/2023 07:31, Richard Biener wrote:
OK.
I do wonder about the gfortran testsuite adjustments though.
!GCC$ builtin (sin) attributes simd (inbranch)
! this should not be using simd clone
y4 = sin(x8)
previously we wouldn't vectorize this as no notinbranch simd function
is ava
Hi,
In a previous patch I did most of the work for this, but forgot to
change the check for number of arguments matching between call and
simdclone. This check should accept calls without a mask to be matched
against simdclones with mask arguments. I also added tests to verify
this feature
the code that constructed the array for
the return value.
Kind regards,
Andre
On 18/10/2023 15:41, Andre Vieira (lists) wrote:
This patch moves the call to TARGET_SIMD_CLONE_ADJUST until after the
arguments and return types have been transformed into vector types. It
also constructs
appy
for you to change this once approved by a maintainer.
Kind regards,
Andre
On 11/10/2023 12:34, Stamatis Markianos-Wright wrote:
Hi all,
On 28/09/2023 13:51, Andre Vieira (lists) wrote:
Hi,
On 14/09/2023 13:10, Kyrylo Tkachov via Gcc-patches wrote:
Hi Stam,
The arm parts look sensib
On 20/10/2023 14:41, Richard Biener wrote:
On Fri, 20 Oct 2023, Andre Vieira (lists) wrote:
Hi,
This patch stops lowering of bitfields by ifcvt when they have non-constant
offsets as we are not likely to be able to do anything useful with those
during
vectorization. That also fixes the
Hi,
This patch stops lowering of bitfields by ifcvt when they have non-constant
offsets as we are not likely to be able to do anything useful with those
during
vectorization. That also fixes the issue reported in PR 111882, which was
being caused by an offset with a side-effect being lowered,
ter return
and argument types have been vectorized.
On 04/10/2023 13:40, Andre Vieira (lists) wrote:
On 04/10/2023 11:41, Richard Biener wrote:
On Wed, 4 Oct 2023, Andre Vieira (lists) wrote:
On 30/08/2023 14:04, Richard Biener wrote:
On Wed, 30 Aug 2023, Andre Vieira (lists) wr
Rebased, no major changes, still needs review.
On 30/08/2023 10:19, Andre Vieira (lists) via Gcc-patches wrote:
This patch finalizes adding support for the generation of SVE simd
clones when no simdlen is provided, following the ABI rules where the
widest data type determines the minimum
Rebased on top of trunk, minor change to check if loop_vinfo since we
now do some slp vectorization for simd_clones.
I assume the previous OK still holds.
On 30/08/2023 13:54, Richard Biener wrote:
On Wed, 30 Aug 2023, Andre Vieira (lists) wrote:
When analyzing a loop and choosing a
Refactor simd clone handling code ahead of support for poly simdlen.
gcc/ChangeLog:
* omp-simd-clone.cc (simd_clone_subparts): Remove.
(simd_clone_init_simd_arrays): Replace simd_clone_supbarts with
TYPE_VECTOR_SUBPARTS.
(ipa_simd_modify_function_body): Likewise.
Rebased, needs review.
On 30/08/2023 10:13, Andre Vieira (lists) via Gcc-patches wrote:
This patch enables the compiler to use inbranch simdclones when
generating masked loops in autovectorization.
gcc/ChangeLog:
* omp-simd-clone.cc (simd_clone_adjust_argument_types): Make function
helper function.
On 30/08/2023 13:54, Richard Biener wrote:
On Wed, 30 Aug 2023, Andre Vieira (lists) wrote:
The vect_get_smallest_scalar_type helper function was using any argument to a
simd clone call when trying to determine the smallest scalar type that would
be vectorized. This included
Posting the changed patch for completion, already reviewed.
On 30/08/2023 13:32, Richard Biener wrote:
On Wed, 30 Aug 2023, Andre Vieira (lists) wrote:
Teach parloops how to handle a poly nit and bound e ahead of the changes to
enable non-constant simdlen.
Can you use poly_int_tree_p to
Just posting a rebase for completion.
On 30/08/2023 13:31, Richard Biener wrote:
On Wed, 30 Aug 2023, Andre Vieira (lists) wrote:
SVE simd clones require to be compiled with a SVE target enabled or the
argument types will not be created properly. To achieve this we need to copy
ings got a
bit confusing with removing and adding patches to the series.
On 30/08/2023 09:49, Andre Vieira (lists) via Gcc-patches wrote:
Hi,
This patch series aims to implement support for SVE simd clones when not
specifying a 'simdlen' clause for AArch64. This patch depends on my
earlie
So OK to commit this?
This patch makes sure the profile_count information is initialized for
the new
bb created in move_sese_region_to_fn.
gcc/ChangeLog:
* tree-cfg.cc (move_sese_region_to_fn): Initialize profile_count for
new basic block.
Bootstrapped and regression tested o
Hey,
Just a minor update to the patch, I had missed the libgomp testsuite, so
had to make some adjustments there too.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (lane_size): New function.
(aarch64_simd_clone_compute_vecsize_and_simdlen): Determine
simdlen according to NDS rul
On 04/10/2023 11:41, Richard Biener wrote:
On Wed, 4 Oct 2023, Andre Vieira (lists) wrote:
On 30/08/2023 14:04, Richard Biener wrote:
On Wed, 30 Aug 2023, Andre Vieira (lists) wrote:
This patch adds a new target hook to enable us to adapt the types of return
and parameters of simd
On 30/08/2023 14:04, Richard Biener wrote:
On Wed, 30 Aug 2023, Andre Vieira (lists) wrote:
This patch adds a new target hook to enable us to adapt the types of return
and parameters of simd clones. We use this in two ways, the first one is to
make sure we can create valid SVE types
Hi Honza,
My current patch set for AArch64 VLA omp codegen started failing on
gcc.dg/gomp/pr87898.c after this. I traced it back to
'move_sese_region_to_fn' in tree/cfg.cc not setting count for the bb
created.
I was able to 'fix' it locally by setting the count of the new bb to the
accumula
On 31/08/2023 07:39, Richard Biener wrote:
On Wed, Aug 30, 2023 at 5:02 PM Andre Vieira (lists)
wrote:
On 30/08/2023 14:01, Richard Biener wrote:
On Wed, Aug 30, 2023 at 11:15 AM Andre Vieira (lists) via Gcc-patches
wrote:
This patch adds a machine_mode parameter to the
Hi,
On 14/09/2023 13:10, Kyrylo Tkachov via Gcc-patches wrote:
Hi Stam,
The arm parts look sensible but we'd need review for the df-core.h and
df-core.cc changes.
Maybe Jeff can help or can recommend someone to take a look?
Thanks,
Kyrill
FWIW the changes LGTM, if we don't want these in
On 26/09/2023 17:37, Andrew Stubbs wrote:
I don't have authority to approve anything, but here's a review anyway.
Thanks for working on this.
Thank you for reviewing and apologies for the mess of a patch, may have
rushed it ;)
diff --git a/gcc/testsuite/gcc.dg/vect/vect-simd-clone-19.c
b
On 26/09/2023 21:26, Bernhard Reutner-Fischer wrote:
On 26 September 2023 18:46:11 CEST, Tobias Burnus
wrote:
On 26.09.23 18:37, Andrew Stubbs wrote:
If the fall-through is deliberate please add a /* FALLTHROUGH */
comment (or whatever spelling disables the warning).
It's: gcc_fallthroug
On 26/09/2023 17:48, Jakub Jelinek wrote:
On Tue, Sep 26, 2023 at 05:24:26PM +0100, Andre Vieira (lists) wrote:
@@ -5816,6 +5817,18 @@ get_references_in_stmt (gimple *stmt, vec *references)
}
case IFN_MASK_LOAD:
case IFN_MASK_STORE:
+ case
The const attribute is ignored when simdclone's are used inbranch. This
is due to the fact that when analyzing a MASK_CALL we were not looking
at the targeted function for flags, but instead only at the internal
function call itself.
This patch adds code to make sure we look at the target functi
1 - 100 of 675 matches
Mail list logo
