sion tests.
Is it OK for trunk?
gcc/ChangeLog:
2018-07-09 Andre Vieira
* config/aarch64/aarch64-option-extensions.def: New entry for profile
extension.
* config/aarch64/aarch64.h (AARCH64_FL_PROFILE): New.
* doc/invoke.texi (aarch64-feature-modifiers): New entry f
On 09/07/18 09:11, Martin Liška wrote:
> Hi.
>
> I'm putting back what I accidentally removed.
>
> Martin
>
> gcc/ChangeLog:
>
> 2018-07-09 Martin Liska
>
> * common.opt: Add back wrongly removed attribute.
> ---
> gcc/common.opt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-
On 09/07/18 22:44, Martin Sebor wrote:
> On 07/09/2018 06:40 AM, Richard Biener wrote:
>> On Sun, Jul 8, 2018 at 4:56 AM Martin Sebor wrote:
>>>
>>> On 07/06/2018 09:52 AM, Richard Biener wrote:
On Fri, Jul 6, 2018 at 1:54 AM Martin Sebor wrote:
>
> GCC folds accesses to members of c
On 11/07/18 11:00, Andre Vieira (lists) wrote:
> On 09/07/18 22:44, Martin Sebor wrote:
>> On 07/09/2018 06:40 AM, Richard Biener wrote:
>>> On Sun, Jul 8, 2018 at 4:56 AM Martin Sebor wrote:
>>>>
>>>> On 07/06/2018 09:52 AM, Richard Biener wrote:
>>
;
>>> I don't know whether it matters in practice, but that description also
>>> applies to Umq, not just Uml. It might be worth changing it too so
>>> that things stay consistent.
>>>
>>> Thanks,
>>> Richard
>>>
>> Hi all,
&g
On 17/07/18 16:23, James Greenhalgh wrote:
> On Mon, Jul 09, 2018 at 08:20:53AM -0500, Andre Vieira (lists) wrote:
>> Hi,
>>
>> This patch adds support for the Statistical Profiling Extension (SPE) on
>> AArch64. Even though the compiler will not generate code an
On 24/07/18 15:12, Richard Biener wrote:
> On Tue, Jul 24, 2018 at 1:44 AM David Malcolm wrote:
>>
>> There are various ways that it's possible for a gimple statement to
>> have an UNKNOWN_LOCATION, and for that UNKNOWN_LOCATION to be wrapped
>> in an ad-hoc location to capture inlining informatio
On 27/07/18 16:39, David Malcolm wrote:
> On Thu, 2018-07-26 at 13:22 +0100, Andre Vieira (lists) wrote:
>
> [...snip...]
>
>>>> diff --git a/gcc/testsuite/gcc.c-torture/compile/pr86636.c
>>>> b/gcc/testsuite/gcc.c-torture/compile/pr86636.c
>>>>
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,
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
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
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
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
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,
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
m mainline
2019-10-18 Andre Vieira
* config/arm/t-multilib: Add new multilib variants and new
mappings.
gcc/testsuite/ChangeLog:
2019-10-21 Mihail Ionescu
Backport from mainline
2019-10-18 Andre Vieira
* gcc.target/arm/multilib.exp: Add extra tests.
Is
On 22/10/2019 18:52, Richard Sandiford wrote:
Thanks for doing this. Hope this message doesn't cover too much old
ground or duplicate too much...
"Andre Vieira (lists)" writes:
@@ -2466,15 +2476,65 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree niters,
tree nit
On 22/10/2019 14:56, Richard Biener wrote:
On Tue, 22 Oct 2019, Andre Vieira (lists) wrote:
Hi Richi,
See inline responses to your comments.
On 11/10/2019 13:57, Richard Biener wrote:
On Thu, 10 Oct 2019, Andre Vieira (lists) wrote:
Hi,
+
+ /* Keep track of vector sizes we know
ation.
Is this OK for trunk?
gcc/ChangeLog:
2019-10-25 Andre Vieira
PR 88915
* tree-ssa-loop-niter.h (simplify_replace_tree): Change declaration.
* tree-ssa-loop-niter.c (simplify_replace_tree): Add context parameter
and make the valueize function pointer also take a vo
Hi,
Reworked according to your comments, see inline for clarification.
Is this OK for trunk?
gcc/ChangeLog:
2019-10-28 Andre Vieira
PR 88915
* tree-ssa-loop-niter.h (simplify_replace_tree): Change declaration.
* tree-ssa-loop-niter.c (simplify_replace_tree): Add context
o when
we advance the DR, we change that field and not the DR_OFFSET? That way
we always keep the "original state".
Cheers,
Andre
gcc/ChangeLog:
2019-10-29 Andre Vieira
PR 88915
* tree-ssa-loop-niter.h (simplify_replace_tree): Change declaration.
* t
Andre Vieira
* params.def (PARAM_VECT_EPILOGUES_NOMASK): Enable by default.
gcc/testsuite/ChangeLog:
2019-10-30 Andre Vieira
* gcc.dg/vect/vect-epilogues.c: New test.
* gcc.dg/vect/fast-math-vect-call-1.c: Disable for epilogue
vectorization.
* gcc.dg
r277664 as obvious.
gcc/testsuite/ChangeLog:
2019-10-31 Andre Vieira
* gcc.target/aarch64/sve/reduc_strict_3.c: Fix option order.
* gcc.target/i386/avx-vzeroupper-19.c: Likewise.
* gcc.target/i386/avx2-vect-mask-store-move1.c: Likewise.
* gcc.target/i386/avx512f-
testism, but would like a second opinion.
Cheers,
Andre
gcc/testsuite/ChangeLog:
2019-10-31 Andre Vieira
* g++.dg/pr80481.C: Disable epilogue vectorization.
diff --git a/gcc/testsuite/g++.dg/pr80481.C b/gcc/testsuite/g++.dg/pr80481.C
index bd5002c89d5137012f36f16946e
On 31/10/2019 14:04, Jakub Jelinek wrote:
On Thu, Oct 31, 2019 at 01:55:26PM +, Andre Vieira (lists) wrote:
I used to have this testcase in my patch when testing but forgot to include
it in the patch I sent upstream. This testcase checks that a vmovaps isn't
generated when vectorizin
that parameter.
Bootstrapped on x86_64 and aarch64.
Is this OK for trunk?
Cheers,
Andre
gcc/ChangeLog:
2019-10-31 Andre Vieira
* tree-vect-loop.c (vect_analyze_loop): Remove orig_loop_vinfo
parameter.
* tree-vectorizer.h (vect_analyze_loop): Update declar
gcc/ChangeLog:
2019-11-04 Andre Vieira
* tree-vect-loop.c (vect_analyze_loop): Disable epilogue
vectorization if loop->simduid is non null.
On 31/10/2019 16:58, Jakub Jelinek wrote:
FAIL: libgomp.c/../libgomp.c-c++-common/loop-1.c execution test
FAIL: libgomp.c/examples-4/si
his makes sure that is true even if these phi-nodes are constants,
fixing PR92317. I copied the failing testcase and added the options
that originally made it fail.
Is this OK for trunk?
Cheers,
Andre
gcc/ChangeLog:
2019-11-05 Andre Vieira
* tree-vect-loop-manip.c (slpeel_update_
his makes sure that is true even if these phi-nodes are constants,
fixing PR92317. I copied the failing testcase and added the options
that originally made it fail.
Is this OK for trunk?
Cheers,
Andre
gcc/ChangeLog:
2019-11-06 Andre Vieira
* tree-vect-loop-manip.c (slpeel_update_
Sorry for the double post, ignore please.
On 06/11/2019 10:57, Andre Vieira (lists) wrote:
Hi,
When investigating PR92317 I noticed that when we create the skip
epilogue condition, see ('if (skip_epilog)' in 'vect_do_peeling'), we
only copy phi-nodes that
analysis
for cases in which both the number of iterations and iterations to peel
are known at compile time, as in that case we shouldn't ever be skipping
the main loop as we shouldn't be generating it.
gcc/ChangeLog:
2019-11-07 Andre Vieira
* tree-vect-d
when defining '$acc parallel
vector_length(vl)' I am looking into it.
Is this OK for trunk?
Cheers,
Andre
gcc/ChangeLog:
2019-11-07 Andre Vieira
* tree-vect-loop.c (vect_analyze_loop): Disable epilogue
vectorization for loops with SIMDUID set. Enable epilogue
On 07/11/2019 14:00, Richard Biener wrote:
On Thu, 7 Nov 2019, Andre Vieira (lists) wrote:
Hi,
PR92351 reports a bug in which a wrongly aligned load is generated for an
epilogue of a main loop for which we peeled for alignment. There is no way to
guarantee that epilogue data accesses are
arch64 and x86_64.
Is this OK for trunk?
Cheers,
Andre
gcc/ChangeLog:
2019-11-08 Andre Vieira
* tree-vect-loop-manip.c (vect_do_peeling): Take epilogue gaps
into account when checking if there are enough iterations to
vectorize epilogue.
gcc/testsuite/ChangeLog:
2019-11
s
context.
Bootstrapped x86_64 and aarch64 and ran libgomp.
Is this OK for trunk? (If approved can someone commit on my behalf as
I'll be away for two weeks?)
Cheers,
Andre
gcc/ChangeLog:
2019-11-11 Andre Vieira
* tree-vect-loop.c (vect_transform_loop): Don't overwrite epilo
_tree function such
that we can optionally disable folding as this patch does in
update_epilogue_loop_vinfo.
Bootstrapped and regression tested on x86_64.
Is this OK for trunk?
gcc/ChangeLog:
2020-01-10 Andre Vieira
PR tree-optimization/92429
* tree-ssa-loop-ni
ative 'innermost_loop_behavior' in
'vect_create_addr_base_for_vector_ref'.
I regression tested vect.exp on aarch64 and x86_64. I also regression
tested libgomp on aarch64 and x86_64, no changes, but there were quite a
few test failures with the commit I based this patch on...
I
Hi,
We can now vectorize an epilogue for this loop for arm too, so removing
xfail.
Is this OK for trunk? Wasn't entirely sure whether I could commit this
under obvious.
gcc/testsuite/ChangeLog:
2019-12-11 Andre Vieira
* gcc.dg/vect/vect-epilogues.c: Remove xfail for arm.
Yeah didn't test that, thanks.
This OK?
gcc/testsuite/ChangeLog:
2019-12-12 Andre Vieira
* gcc.dg/vect/vect-epilogues.c: XFAIL for arm big endian.
* lib/target-supports.exp (check_effective_target_arm_big_endian):
New target selector.
On 12/12/2019
Thanks for pointing it out Rainer. Thanks to that reminder I noticed
there is a different way to achieve this without adding that extra
target check.
This OK?
gcc/testsuite/ChangeLog:
2019-12-12 Andre Vieira
* gcc.dg/vect/vect-epilogues.c: XFAIL for arm big endian.
On 12/12/2019
Consequently whilst looking at the list I noticed these two were missing.
This OK for trunk?
gcc/ChangeLog:
2019-12-13 Andre Vieira
* doc/sourcebuild.texi (arm_little_endian, arm_nothumb):
Documented existing target checks.
On 13/12/2019 13:05, Andre Vieira (lists) wrote
Hello,
Should we try to get this refactoring in stage 3 or park it for next
stage 1?
Cheers,
Andre
On 10/12/2019 13:36, Andre Vieira (lists) wrote:
Hi,
This patch aims at refactoring the vectorizer code to no longer need to
reset DR_OFFSET for epilogue vectorization and instead keep track
What about the previous patch fixing the existing testism by skipping
for big-endian arm using existing target supports?
On 07/01/2020 07:31, Richard Biener wrote:
On Fri, 13 Dec 2019, Andre Vieira (lists) wrote:
Consequently whilst looking at the list I noticed these two were missing.
This
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
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,
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,
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 c
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
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
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.
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
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/
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
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
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
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
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
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
* gcc.target/aarch64/bitint-args.c: New test.
* gcc.target/aarch64/bitint-sizes.c: New test.
On 02/02/2024 14:46, Jakub Jelinek wrote:
On Thu, Jan 25, 2024 at 05:45:01PM +, Andre Vieira wrote:
This patch adds support for C23's _BitInt for the AArch64 port when compiling
f
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
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
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
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 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 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
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 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
): 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
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
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/g
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-Dec
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
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
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
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
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
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,
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
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
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: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
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
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
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
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
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
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,
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
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,
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
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
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
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
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
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.
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
should be, which caused an ICE.
This dec_insn is the instruction that decreases the loop counter
inside a
decrementing loop a
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:
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
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
101 - 200 of 765 matches
Mail list logo
