ndre
gcc
2018-06-xx Andre Vieira
* config/arm/arm_cmse.h (cmse_nsfptr_create): Change typeof to
__typeof__.
(cmse_check_pointed_opject): Idem.
gcc/testsuite
2018-06-xx Andre Vieira
* gcc.target/arm/cmse/cmse-1c99.c: New test.
On 05/06/18 10:42, Kyrill Tkachov wrote:
> Hi Andre,
>
> On 05/06/18 10:40, Andre Vieira (lists) wrote:
>> Hi all,
>>
>> This patch makes the arm_cmse.h header file ISO C compliant. We were
>> using 'typeof' before when we should be using '__typeof
PEC_PRED_X.
If there is a firm belief the UNSPEC_LD1_SVE will not be used for
anything I am also happy to refactor it out.
Bootstrapped and regression tested aarch64-none-linux-gnu.
Is this OK for trunk?
Kind regards,
Andre Vieira
gcc/ChangeLog:
2021-05-14 Andre Vieira
* config/aarch
Hi,
So this is my second attempt at finding a way to improve how we generate
the vector IV's and teach the vectorizer to share them between main loop
and epilogues. On IRC we discussed my idea to use the loop's control_iv,
but that was a terrible idea and I quickly threw it in the bin. The mai
the
extending aarch64_load_* patterns accept both UNSPEC_LD1_SVE and
UNSPEC_PRED_X.
Is this OK for trunk?
Kind regards,
Andre Vieira
gcc/ChangeLog:
2021-05-18 Andre Vieira
* config/aarch64/iterators.md (SVE_PRED_LOAD): New iterator.
(pred_load): New int attribute.
* con
Hi,
When vectorizing with --param vect-partial-vector-usage=1 the vectorizer
uses an unpredicated (all-true predicate for SVE) main loop and a
predicated tail loop. The way this was implemented seems to mean it
re-uses the same vector-mode for both loops, which means the tail loop
isn't an ac
Thank you Kewen!!
I will apply this now.
BR,
Andre
On 25/05/2021 09:42, Kewen.Lin wrote:
on 2021/5/24 下午3:21, Kewen.Lin via Gcc-patches wrote:
Hi Andre,
on 2021/5/24 下午2:17, Andre Vieira (lists) via Gcc-patches wrote:
Hi,
When vectorizing with --param vect-partial-vector-usage=1 the
Hi,
This RFC is motivated by the IV sharing RFC in
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569502.html and the
need to have the IVOPTS pass be able to clean up IV's shared between
multiple loops. When creating a similar problem with C code I noticed
IVOPTs treated IV's with uses ou
Streams got crossed there and used the wrong subject ...
On 03/06/2021 17:34, Andre Vieira (lists) via Gcc-patches wrote:
Hi,
This RFC is motivated by the IV sharing RFC in
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569502.html and the
need to have the IVOPTS pass be able to clean up
Hi,
This is a gcc-9 backport of the PR97528 fix that has been applied to
trunk and gcc-10.
Bootstraped on arm-linux-gnueabihf and regression tested.
OK for gcc-9 branch?
2021-02-02 Andre Vieira
Backport from mainline
2020-11-20 Jakub Jelinek
PR target/97528
* config
Same patch applies cleanly on gcc-8, bootstrapped
arm-none-linux-gnueabihf and ran regressions also clean.
Can I also commit it to gcc-8?
Thanks,
Andre
On 02/02/2021 17:36, Kyrylo Tkachov wrote:
-Original Message-
From: Andre Vieira (lists)
Sent: 02 February 2021 17:27
To: gcc
This patch introduces a vect.mul RTX cost and decouples the vector
multiplication costing from the scalar one.
After Wilco's "AArch64: Add cost table for Cortex-A76" patch we saw a
regression in vector codegen. Reproduceable with the small test added in
this patch.
Upon further investigation w
or other targets, so not sure it makes sense to test on
others?
Is this OK for trunk? Would you rather wait for the testcase?
gcc/ChangeLog:
2021-02-05 Andre Vieira
PR middle-end/98974
* tree-vect-stmts.c (vectorizable_condition): Fix nvectors parameter
fo
On 05/02/2021 12:47, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
Hi,
As mentioned in the PR, this patch fixes up the nvectors parameter passed to
vect_get_loop_mask in vectorizable_condition.
Before the STMT_VINFO_VEC_STMTS rework we used to handle each ncopy separa
Hi,
This patch prevents generating a vec_duplicate with illegal predicate.
Regression tested on aarch64-linux-gnu.
OK for trunk?
gcc/ChangeLog:
2021-02-17 Andre Vieira
PR target/98657
* config/aarch64/aarch64-sve.md: Use 'expand_vector_broadcast'
to emit vec_d
updating allocno copy costs.
Regression tested on aarch64-linux-gnu.
Is this OK for trunk (and after a week backport to gcc-10) ?
Regards,
Andre
gcc/ChangeLog:
2021-02-19 Andre Vieira
PR rtl-optimization/98791
* ira-conflicts.c (process_regs_for_copy): Don't create al
Hi Alex,
On 22/02/2021 10:20, Alex Coplan wrote:
For the testcase, you might want to use the one I posted most recently:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98791#c3
which avoids the dependency on the aarch64-autovec-preference param
(which is in GCC 11 only) as this will simplify backp
On 19/02/2021 15:05, Vladimir Makarov wrote:
On 2021-02-19 5:53 a.m., Andre Vieira (lists) wrote:
Hi,
This patch makes sure that allocno copies are not created for
unordered modes. The testcases in the PR highlighted a case where an
allocno copy was being created for:
(insn 121 120 123
LGTM, but please wait for maintainer review.
On 25/11/2020 13:54, Christophe Lyon via Gcc-patches wrote:
This patch enables MVE veorq instructions for auto-vectorization. MVE
veorq insns in mve.md are modified to use xor instead of unspec
expression to support xor3. The xor3 expander is added
Hi Christophe,
On 26/11/2020 15:31, Christophe Lyon wrote:
Hi Andre,
Thanks for the quick feedback.
On Wed, 25 Nov 2020 at 18:17, Andre Simoes Dias Vieira
wrote:
Hi Christophe,
Thanks for these! See some inline comments.
On 25/11/2020 13:54, Christophe Lyon via Gcc-patches wrote:
This pat
On 08/12/2020 13:50, Christophe Lyon via Gcc-patches wrote:
Hi,
My 'vand' patch changes the definition of VDQ so that the relevant
modes are enabled only when !TARGET_HAVE_MVE (V8QI, ...), and this
helps writing a simpler expander.
However, vneg is used by vshr (right-shifts by register are
tion for which I haven't quite worked out a
solution yet and does cause some minor regressions due to unfortunate
spills.
Let me know what you think and if you have ideas of how we can better
achieve this.
Kind regards,
Andre Vieira
diff --git a/gcc/tree-vect-loop-manip.c
Hi Christophe,
On 30/04/2021 15:09, Christophe Lyon via Gcc-patches wrote:
Since MVE has a different set of vector comparison operators from
Neon, we have to update the expansion to take into account the new
ones, for instance 'NE' for which MVE does not require to use 'EQ'
with the inverted con
It would be good to also add tests for NEON as you also enable auto-vec
for it. I checked and I do think the necessary 'neon_vc' patterns exist
for 'VH', so we should be OK there.
On 30/04/2021 15:09, Christophe Lyon via Gcc-patches wrote:
This patch adds __fp16 support to the previous patch t
Hi Christophe,
The series LGTM but you'll need the approval of an arm port maintainer
before committing. I only did code-review, did not try to build/run tests.
Kind regards,
Andre
On 30/04/2021 15:09, Christophe Lyon via Gcc-patches wrote:
This patch enables MVE vld4/vst4 instructions for a
th vector and scalar!) and then
teach it to merge IV's if one ends where the other begins?
On 04/05/2021 10:56, Richard Biener wrote:
On Fri, 30 Apr 2021, Andre Vieira (lists) wrote:
Hi,
The aim of this RFC is to explore a way of cleaning up the codegen around
data_references. To be s
On 05/05/2021 13:34, Richard Biener wrote:
On Wed, 5 May 2021, Andre Vieira (lists) wrote:
I tried to see what IVOPTs would make of this and it is able to analyze the
IVs but it doesn't realize (not even sure it tries) that one IV's end (loop 1)
could be used as the base for the o
are reservations about making these changes this late in the
development stage, unfortunately I didn't get around to fixing them earlier.
Andre Vieira (3):
arm: Fix sign of MVE predicate mve_pred16_t [PR 107674]
arm: Remove unnecessary zero-extending of MVE predicates before use [PR
107674]
Hi,
The ACLE defines mve_pred16_t as an unsigned short. This patch makes
sure GCC treats the predicate as an unsigned type, rather than signed.
Bootstrapped on aarch64-none-eabi and regression tested on arm-none-eabi
and armeb-none-eabi for armv8.1-m.main+mve.fp.
OK for trunk?
gcc/ChangeL
I meant bootstrapped on aarch64-none-linux-gnu and not none-eabi.
On 24/01/2023 13:40, Andre Vieira (lists) via Gcc-patches wrote:
Hi,
The ACLE defines mve_pred16_t as an unsigned short. This patch makes
sure GCC treats the predicate as an unsigned type, rather than signed.
Bootstrapped on
Hi,
This patch teaches GCC that zero-extending a MVE predicate from 16-bits
to 32-bits and then only using 16-bits is a no-op.
It does so in two steps:
- it lets gcc know that it can access any MVE predicate mode using any
other MVE predicate mode without needing to copy it, using the
TARGET_
Hi,
This patch fixes the way we synthesize MVE predicate immediates and
fixes some other inconsistencies around predicates. For instance this
patch fixes the modes used in the vctp intrinsics, to couple them with
predicate modes with the appropriate lane numbers. For this V2QI is
added to rep
ping. (reattaching patch in the hopes patchwork picks it up).
On 13/01/2023 16:05, Andre Simoes Dias Vieira via Gcc-patches wrote:
Hi,
This patch adds the memory operand of MVE masked stores as input operands to
mimic the 'partial' writes, to prevent erroneous write-after-write
optimizations as
Hi,
This patch adds aarch64 to the list of vect_long_long targets.
Regression tested on aarch64-none-linux-gnu.
OK for trunk?
gcc/testsuite/ChangeLog:
* lib/target-supports.exp (check_effective_target_vect_long_long): Add
aarch64 to list of targets supporting long long vector
Looks like the first patch was missing a change I had made to prevent
mve_bool_vec_to_const ICEing if called with a non-vector immediate. Now
included.
On 24/01/2023 13:56, Andre Vieira (lists) via Gcc-patches wrote:
Hi,
This patch fixes the way we synthesize MVE predicate immediates and
On 26/01/2023 15:02, Kyrylo Tkachov wrote:
Hi Andre,
-Original Message-
From: Andre Vieira (lists)
Sent: Tuesday, January 24, 2023 1:41 PM
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov ; Richard Earnshaw
Subject: [PATCH 1/3] arm: Fix sign of MVE predicate mve_pred16_t [PR
107674
On 26/01/2023 15:06, Kyrylo Tkachov wrote:
Hi Andre,
-Original Message-
From: Andre Vieira (lists)
Sent: Tuesday, January 24, 2023 1:54 PM
To: gcc-patches@gcc.gnu.org
Cc: Richard Sandiford ; Richard Earnshaw
; Richard Biener ;
Kyrylo Tkachov
Subject: [PATCH 2/3] arm: Remove
This applies cleanly to gcc-12 and regressions for arm-none-eabi look clean.
OK to apply to gcc-12?
On 06/12/2022 11:23, Kyrylo Tkachov wrote:
-Original Message-
From: Andre Simoes Dias Vieira
Sent: Tuesday, December 6, 2022 11:19 AM
To: 'gcc-patches@gcc.gnu.org'
Cc: Kyrylo Tkach
Here's a new version with a more robust test.
OK for trunk?
On 27/01/2023 09:56, Kyrylo Tkachov wrote:
-Original Message-
From: Andre Vieira (lists)
Sent: Friday, January 27, 2023 9:54 AM
To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
Cc: Richard Earnshaw
Subject: Re: [PATC
Changed the testcase to be more robust (as per the discussion for the
first patch).
Still need the OK for the mid-end (simplify-rtx) part.
Kind regards,
Andre
On 27/01/2023 09:59, Kyrylo Tkachov wrote:
-Original Message-
From: Andre Vieira (lists)
Sent: Friday, January 27, 2023 9
Yeah that shouldn't be there, it's from an earlier version of the patch
I wrote where I was experimenting changing the existing modes, I'll
remove it from the ChangeLog.
On 31/01/2023 09:53, Kyrylo Tkachov wrote:
gcc/testsuite/ChangeLog:
* gcc.dg/rtl/arm/mve-vxbi.c: Use new pred
rylo Tkachov wrote:
-Original Message-
From: Richard Sandiford
Sent: Tuesday, November 15, 2022 6:05 PM
To: Andre Simoes Dias Vieira
Cc: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
Richard Earnshaw
Subject: Re: [PATCH 2/2] aarch64: Add support for widening LDAPR
instructions
"Andre
Ping.
On 25/08/2022 10:09, Andre Vieira (lists) via Gcc-patches wrote:
On 17/08/2022 13:49, Richard Biener wrote:
Yes, of course. What you need to do is subtract DECL_FIELD_BIT_OFFSET
of the representative from DECL_FIELD_BIT_OFFSET of the original
bitfield
access - that's the o
On 08/09/2022 12:51, Richard Biener wrote:
I'm curious, why the push to redundant_ssa_names? That could use
a comment ...
So I purposefully left a #if 0 #else #endif in there so you can see the
two options. But the reason I used redundant_ssa_names is because ifcvt
seems to use that as a con
On 27/09/2022 13:34, Richard Biener wrote:
On Mon, 26 Sep 2022, Andre Vieira (lists) wrote:
On 08/09/2022 12:51, Richard Biener wrote:
I'm curious, why the push to redundant_ssa_names? That could use
a comment ...
So I purposefully left a #if 0 #else #endif in there so you can see th
ite-3.c: New test.
* gcc.dg/vect/vect-bitfield-write-4.c: New test.
* gcc.dg/vect/vect-bitfield-write-5.c: New test.
On 28/09/2022 10:43, Andre Vieira (lists) via Gcc-patches wrote:
On 27/09/2022 13:34, Richard Biener wrote:
On Mon, 26 Sep 2022, Andre Vieira (lists) wrote:
On
Hi all,
Can I backport this to gcc-11 branch? Also applies cleanly (with the
exception of the file extensions being different: 'aarch64-builtins.cc
vs aarch64-builtins.c').
Bootstrapped and regression tested on aarch64-linux-gnu.
Kind regards,
Andre Vieira
nges Richard, but I don't like to
commit on Friday in case something breaks over the weekend, so I'll
leave it until Monday.
Thanks,
Andre
On 29/09/2022 08:54, Richard Biener wrote:
On Wed, Sep 28, 2022 at 7:32 PM Andre Vieira (lists) via Gcc-patches
wrote:
Made the change and also
Hi,
This patch enables the use of mixed-types for simd clones for AArch64
and adds aarch64 as a target_vect_simd_clones.
Bootstrapped and regression tested on aarch64-unknown-linux-gnu
gcc/ChangeLog:
* config/aarch64/aarch64.cc (currently_supported_simd_type):
Remove.
(aarch
cc.dg/gomp/pr87887-1.c: Add warning test.
* gcc.dg/gomp/pr89246-1.c: Likewise.
* gcc.dg/gomp/pr99542.c: Update warning test.
On 08/08/2023 11:51, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
warning_at (DECL_SOURCE_LOCA
On 09/08/2023 17:55, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
On 08/08/2023 11:51, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
- "unsupported ret
Hi,
This patch enables the use of mixed-types for simd clones for AArch64,
adds aarch64 as a target_vect_simd_clones and corrects the way the
simdlen is chosen for non-specified simdlen clauses according to the
'Vector Function Application Binary Interface Specification for AArch64'.
Additio
on
aarch64-unknown-linux-gnu and x86_64-pc-linux-gnu. I also tried building
the patches separately, but that was before some further clean-up
restructuring, so will do that again prior to pushing.
Andre Vieira (8):
parloops: Copy target and optimizations when creating a function clone
parloops
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 DECL_FUNCTION_SPECIFIC_TARGET from the original function
declaration to the clones. I decided it was probably also a good idea
to copy DECL_FUN
Teach parloops how to handle a poly nit and bound e ahead of the changes
to enable non-constant simdlen.
gcc/ChangeLog:
* tree-parloops.cc (try_to_transform_to_exit_first_loop_alt): Accept
poly NIT and ALT_BOUND.diff --git a/gcc/tree-parloops.cc b/gcc/tree-parloops.cc
index
a35
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 the function pointer type in a
MASK_CALL for instance, and would result in the wrong type being
selected. Ins
When analyzing a loop and choosing a simdclone to use it is possible to
choose a simdclone that cannot be used 'inbranch' for a loop that can
use partial vectors. This may lead to the vectorizer deciding to use
partial vectors which are not supported for notinbranch simd clones.
This patch fix
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
compatible with mask parameters in clone.
* tree-vect-stmts.cc (vect_convert
This patch adds a machine_mode parameter to the TARGET_SIMD_CLONE_USABLE
hook to enable rejecting SVE modes when the target architecture does not
support SVE.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_simd_clone_usable): Add mode
parameter and use to to reject SVE mod
Forgot to CC this one to maintainers...
On 30/08/2023 10:14, Andre Vieira (lists) via Gcc-patches wrote:
This patch adds a machine_mode parameter to the TARGET_SIMD_CLONE_USABLE
hook to enable rejecting SVE modes when the target architecture does not
support SVE.
gcc/ChangeLog
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, including the
SVE type attribute, when creating a SVE simd clone, even when the target
options do not
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 amount of elements in a length
agnostic vector.
gcc/ChangeLog:
* config/aarch64/aarch64-protos.h (add_sve_ty
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 TARGET_SIMD_CLONE_USABLE
hook to enable rejecting SVE modes when the target architecture does not
support SVE.
How does
On 17/06/2022 11:54, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
Hi,
This patch adds support for the ACLE Data Intrinsics to the AArch64 port.
Bootstrapped and regression tested on aarch64-none-linux.
OK for trunk?
Sorry for the slow review.
On 29/06/2022 08:18, Richard Sandiford wrote:
+ break;
+case AARCH64_RBIT:
+case AARCH64_RBITL:
+case AARCH64_RBITLL:
+ if (mode == SImode)
+ icode = CODE_FOR_aarch64_rbitsi;
+ else
+ icode = CODE_FOR_aarch64_rbitdi;
+ break;
+default:
+ gcc_u
Hi,
This is a RFC for my prototype for bitfield read vectorization. This
patch enables bit-field read vectorization by removing the rejection of
bit-field read's during DR analysis and by adding two vect patterns. The
first one transforms TREE_COMPONENT's with BIT_FIELD_DECL's into
BIT_FIELD_
Thanks Jakub!
I do need those includes and sorry I broke your bootstrap it didn't show
up on my aarch64-unknown-linux-gnu bootstrap, I'm guessing the rules
there were just run in a different order. Glad you were able to fix it :)
On 06/06/2023 22:28, Jakub Jelinek wrote:
Hi!
internal-fn.h s
Hi,
This patch fixes an issue introduced by
g:2f482a07365d9f4a94a56edd13b7f01b8f78b5a0, where a subtype was beeing
passed to vect_widened_op_tree, when no subtype was to be used. This
lead to an errorneous use of IFN_VEC_WIDEN_MINUS.
gcc/ChangeLog:
* tree-vect-patterns.cc (vect_reco
On 05/06/2023 04:04, Jan Hubicka wrote:
On Thu, 1 Jun 2023, Andre Vieira (lists) wrote:
Hi,
This is a follow-up of the internal function patch to add widening and
narrowing patterns. This patch improves the inliner cost estimation for
internal functions.
I have no idea why calls are
Some comments below, all quite minor. I'll continue to review tomorrow,
I need a fresher brain for arm_mve_check_df_chain_back_for_implic_predic
;)
+static int
+arm_mve_get_vctp_lanes (rtx x)
+{
+ if (GET_CODE (x) == SET && GET_CODE (XEXP (x, 1)) == UNSPEC
+ && (XINT (XEXP (x, 1), 1) ==
+ if (insn != arm_mve_get_loop_vctp (body))
+{
probably a good idea to invert the condition here and return false,
helps reducing the indenting in this function.
+ /* Starting from the current insn, scan backwards through the insn
+ chain until BB_HEAD: "for each insn in t
+ /* In order to find out if the loop is of type A or B above look for the
+ loop counter: it will either be incrementing by one per iteration or
+ it will be decrementing by num_of_lanes. We can find the loop counter
+ in the condition at the end of the loop. */
+ rtx_insn *loop_c
Hi,
This patch makes the vectorizer treat any vector widening IFN as simple,
like
it did with the tree codes VEC_WIDEN_*.
I wasn't sure whether I should make all IFN's simple and then exclude
some (like GOMP_ ones), or include more than just the new widening IFNs.
But since this is the only
Hi,
This patch fixes PR110610 by including OPTABS_H in the INTERNAL_FN_H
list, as insn-opinit.h is now required by internal-fn.h. This will lead
to insn-opinit.h, among the other OPTABS_H header files, being installed
in the plugin directory.
Bootstrapped aarch64-unknown-linux-gnu.
@Jakub:
On 11/07/2023 23:28, Jeff Law wrote:
On 7/11/23 04:37, Andre Vieira (lists) via Gcc-patches wrote:
Hi,
This patch fixes PR110610 by including OPTABS_H in the INTERNAL_FN_H
list, as insn-opinit.h is now required by internal-fn.h. This will
lead to insn-opinit.h, among the other OPTABS_H
On 15/05/2023 12:01, Richard Biener wrote:
On Mon, 15 May 2023, Richard Sandiford wrote:
Richard Biener writes:
On Fri, 12 May 2023, Richard Sandiford wrote:
Richard Biener writes:
On Fri, 12 May 2023, Andre Vieira (lists) wrote:
I have dealt with, I think..., most of your comments
How about this?
Not sure about the DEF_INTERNAL documentation I rewrote in
internal-fn.def, was struggling to word these, so improvements welcome!
gcc/ChangeLog:
2023-04-25 Andre Vieira
Joel Hutton
Tamar Christina
* config/aarch64/aarch64-simd.md
US_HI.
gcc/ChangeLog:
2023-04-25 Andre Vieira
Joel Hutton
Tamar Christina
* config/aarch64/aarch64-simd.md
(vec_widen_addl_lo_): Rename
this ...
(vec_widen_add_lo_): ... to this.
(vec_widen_addl_hi_): Rename this ...
(vec_w
Hi,
This is a follow-up of the internal function patch to add widening and
narrowing patterns. This patch improves the inliner cost estimation for
internal functions.
Bootstrapped and regression tested on aarch64-unknown-linux-gnu.
gcc/ChangeLog:
* ipa-fnsummary.cc (analyze_functio
Hi,
This patch adds gimple-range information for the new IFN_VEC_WIDEN_PLUS*
internal functions, identical to what VEC_WIDEN_PLUS did.
Bootstrapped and regression tested on aarch64-unknown-linux-gnu.
gcc/ChangeLog:
* gimple-range-op.cc (gimple_range_op_handler::maybe_non_standard):
On 02/06/2023 10:13, Richard Biener wrote:
On Thu, 1 Jun 2023, Andre Vieira (lists) wrote:
Hi,
This is a follow-up of the internal function patch to add widening and
narrowing patterns. This patch improves the inliner cost estimation for
internal functions.
I have no idea why calls are
Hi Richard,
Thanks for the review, I don't completely understand all of the below,
so I added some extra questions to help me understand :)
On 27/07/2022 12:37, Richard Biener wrote:
On Tue, 26 Jul 2022, Andre Vieira (lists) wrote:
I don't think this is a good approach for what yo
On 29/07/2022 11:31, Jakub Jelinek wrote:
On Fri, Jul 29, 2022 at 09:57:29AM +0100, Andre Vieira (lists) via Gcc-patches
wrote:
The 'only on the vectorized code path' remains the same though as vect_recog
also only happens on the vectorized code path right?
if conversion (in
On 29/07/2022 11:52, Richard Biener wrote:
On Fri, 29 Jul 2022, Jakub Jelinek wrote:
On Fri, Jul 29, 2022 at 09:57:29AM +0100, Andre Vieira (lists) via Gcc-patches
wrote:
The 'only on the vectorized code path' remains the same though as vect_recog
also only happens on the vecto
was trying to get the series ready to post to make sure the first
patches were in the right shape.
I have put this work on hold right now, but I heard Prathamesh might
want to pick this up, feel free to use any of this, or discard as you
see fit.
Andre Vieira (4)
aarch64: Encourage use of GPR
x27; in the next
patch in this series.
Bootstrapped and regression tested together with the next patch on
aarch64-none-linux-gnu.
gcc/ChangeLog:
2022-08-05 Andre Vieira
* config/aarch64/aarch64-simd.md (aarch64_simd_vec_set):
Remove '?' modifier.diff --git a/gcc/config/aarc
ChangeLog:
2022-08-05 Andre Vieira
* config/aarch64/aarch64.cc (aarch64_vec_duplicate): New.
(aarch64_expand_vector_init): Make the existing variant construct
a rtx_vector_builder from the list of elements and use this to
detect
duplicate patterns.
gcc/teste
Hi,
This patch is part of the WIP patch that follows in this series. It's
goal is to teach forwprop to handle VLA VEC_PERM_EXPRs with VLS
CONSTRUCTORs as arguments as preparation for the 'VLA constructor' hook
approach.
Kind Regards,
Andrediff --git a/gcc/match.pd b/gcc/match.pd
index
97363
This isn't really a 'PATCH' yet, it's something I was working on but had
to put on hold. Feel free to re-use any bits or trash all of it if you'd
like.diff --git a/gcc/config/aarch64/aarch64-sve-builtins-base.cc
b/gcc/config/aarch64/aarch64-sve-builtins-base.cc
index
82f9eba5c397af04924bdebdc68
7; this change of behavior to
ifcvt, and/or we should change the name of the pass, since it's doing
more than if-conversion now?
Bootstrapped and regression tested this patch on aarch64-none-linux-gnu.
gcc/ChangeLog:
2022-08-08 Andre Vieira
* tree-if-conv.cc (includes): Add ex
OK to backport this to gcc-12? Applies cleanly and did a bootstrat and
regression test on aarch64-linux-gnu
Regards,
Andre
On 01/07/2022 12:26, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
On 29/06/2022 08:18, Richard Sandiford wrote:
+ break;
+case AA
Hi,
New version of the patch attached, but haven't recreated the ChangeLog
yet, just waiting to see if this is what you had in mind. See also some
replies to your comments in-line below:
On 09/08/2022 15:34, Richard Biener wrote:
@@ -2998,7 +3013,7 @@ ifcvt_split_critical_edges (class loop
On 17/08/2022 13:49, Richard Biener wrote:
Yes, of course. What you need to do is subtract DECL_FIELD_BIT_OFFSET
of the representative from DECL_FIELD_BIT_OFFSET of the original bitfield
access - that's the offset within the representative (by construction
both fields share DECL_FIELD_OFFSET).
Hi,
The original patch to fix this PR broke the if-conversion of calls into
IFN_MASK_CALL. This patch restores that original behaviour and makes
sure the tests added earlier specifically test inbranch SIMD clones.
Bootstrapped and regression tested on aarch64-none-linux-gnu and
x86_64-pc-li
On 13/04/2023 11:01, Andrew Stubbs wrote:
Hi Andre,
I don't have a cascadelake device to test on, nor any knowledge about
what makes it different from regular x86_64.
Not sure you need one, but yeah I don't know either, it looks like it
fails because:
in-branch vector clones are not yet
On 13/04/2023 15:00, Richard Biener wrote:
On Thu, Apr 13, 2023 at 3:00 PM Andre Vieira (lists) via Gcc-patches
wrote:
On 13/04/2023 11:01, Andrew Stubbs wrote:
Hi Andre,
I don't have a cascadelake device to test on, nor any knowledge about
what makes it different from regular x
Resending this to everyone (sorry for the double send Richard).
On 14/04/2023 09:15, Andre Vieira (lists) wrote:
>
>
> On 14/04/2023 07:55, Richard Biener wrote:
>> On Thu, Apr 13, 2023 at 4:25 PM Andre Vieira (lists)
>> wrote:
>>>
>>>
>>>
>&g
On 14/04/2023 10:09, Richard Biener wrote:
On Fri, Apr 14, 2023 at 10:43 AM Andre Vieira (lists)
wrote:
Resending this to everyone (sorry for the double send Richard).
On 14/04/2023 09:15, Andre Vieira (lists) wrote:
>
>
> On 14/04/2023 07:55, Richard Biener wrote:
>&
I have (outdated) RFC's here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613593.html
I am working on this patch series for stage 1. The list of features I am
working on are:
* SVE support for #pragma omp declare simd
* Support for simdclone usage in autovec from #pragma omp declare v
On the other thread I commented that inbranch simdclones are failing for
AVX512F because it sets the mask_mode, for which inbranch hasn't been
implemented, and so it is rejected.
On 14/04/2023 11:25, Jakub Jelinek via Gcc-patches wrote:
On Fri, Apr 14, 2023 at 10:15:06AM +, Richard Biener
501 - 600 of 731 matches
Mail list logo
