'==' with calls to 'rtx_equal_p (op1,
op2, NULL)'.
Sound good?
Kind regards,
Andre
From: Richard Earnshaw (lists)
Sent: Tuesday, January 30, 2024 11:36 AM
To: Andre Simoes Dias Vieira; gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov; Stam Markianos-Wright
suspect that cascadelake doesn't support these
inbranch simdclones or the vector types it is trying to use.
Kind regards,
Andre
From: haochen.jiang
Sent: Thursday, April 13, 2023 2:48 AM
To: Andre Simoes Dias Vieira; gcc-regress...@gcc.gnu.org;
gcc-patches
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 described in the PR.
Regression tested on arm-none-eabi for armv8.1-m.main+mve.fp.
OK for trunk?
gcc/ChangeLog:
PR
Hi,
This patch surrounds the scalar operand of the MVE vcmp patterns with a
vec_duplicate to ensure both operands of the comparision operator have the same
(vector) mode.
Regression tested on arm-none-eabi. Is this OK for trunk? And a backport to GCC
12?
gcc/ChangeLog:
PR
On 20/01/2022 09:23, Christophe Lyon wrote:
On Wed, Jan 19, 2022 at 8:03 PM Andre Vieira (lists) via Gcc-patches
wrote:
On 13/01/2022 14:56, Christophe Lyon via Gcc-patches wrote:
> The vmvnq_n* intrinsics and have [u]int[16|32]_t arguments, so use
> iterator instead of HI
On 12/11/2021 10:56, Richard Biener wrote:
On Thu, 11 Nov 2021, Andre Vieira (lists) wrote:
Hi,
This patch introduces two IFN's FTRUNC32 and FTRUNC64, the corresponding
optabs and mappings. It also creates a backend pattern to implement them for
aarch64 and a match.pd pattern to idiom
Hi Bin,
Thank you for the reply, I have some questions, see below.
On 07/06/2021 12:28, Bin.Cheng wrote:
On Fri, Jun 4, 2021 at 12:35 AM Andre Vieira (lists) via Gcc-patches
wrote:
Hi Andre,
I didn't look into the details of the IV sharing RFC. It seems to me
costing outside uses is trying
Hi Christophe,
Thanks for these! See some inline comments.
On 25/11/2020 13:54, Christophe Lyon via Gcc-patches wrote:
This patch enables MVE vandq instructions for auto-vectorization. MVE
vandq insns in mve.md are modified to use 'and' instead of unspec
expression to support and3. The and3
On 07/07/2020 13:43, Christophe Lyon wrote:
Hi,
On Mon, 6 Jul 2020 at 16:31, Andre Vieira (lists)
wrote:
On 30/06/2020 14:50, Andre Vieira (lists) wrote:
On 29/06/2020 11:15, Christophe Lyon wrote:
On Mon, 29 Jun 2020 at 10:56, Andre Vieira (lists)
wrote:
On 23/06/2020 21:52,
On 18/06/18 09:08, Andre Simoes Dias Vieira wrote:
> Hi Richard,
>
> Sorry for the delay I have been on holidays. I had a look and I think you
> are right. With these changes Umq and Uml seem to have the same
> functionality though, so I would suggest using only one. Maybe use
On 14/06/18 12:47, Richard Sandiford wrote:
> Kyrill Tkachov writes:
>> Hi Andre,
>> On 07/06/18 18:02, Andre Simoes Dias Vieira wrote:
>>> Hi,
>>>
>>> See below a patch to address PR 83009.
>>>
>>> Tested with aarch64-linux-gnu bootstr
Hey Kyrill,
I think it should be possible, I'll have a quick look.
Cheers,
Andre
From: Kyrill Tkachov
Sent: Wednesday, June 20, 2018 9:32:50 AM
To: Andre Simoes Dias Vieira; gcc-patches@gcc.gnu.org
Cc: nd; James Greenhalgh; Richard Earnshaw; Marcus
Hi,
This patch teaches the AArch64 backend that AES instructions with a XOR and
zero operands can be simplified by replacing the operands of the AES with XOR's
thus eliminating the XOR. This is OK because the AES instruction XORs the input
operands.
This will improve code-generation when
Hi,
This patch teaches the AArch64 backend that the AESE and AESD unspecs are
commutative (which correspond to the vaeseq_u8 and vaesdq_u8 intrinsics). This
improves register allocation around their corresponding instructions avoiding
unnecessary moves.
For instance, with the old patterns
Hi,
This patch series aims to improve codegen for the AArch64 AES instructions by
doing two things.
The first is to make the AES unspecs commutative and by consequence make the
corresponding intrinsics commutative, since the instructions themselves are
commutative in the input.
This will
_
From: Richard Sandiford
Sent: Thursday, June 14, 2018 12:28:16 PM
To: Andre Simoes Dias Vieira
Cc: gcc-patches@gcc.gnu.org; nd
Subject: Re: [AArch64][PATCH 1/2] Fix addressing printing of LDP/STP
Andre Simoes Dias Vieira writes:
> @@ -5716,10 +5717,17 @@ aarch64_classify_ad
Hi,
The address printing for LDP/STP patterns that don't use parallel was not
working properly when dealing with a post-index addressing mode. The post-index
address printing uses the mode's size to determine the post-index immediate.
To fix an earlier issue with range checking of these
Hi,
See below a patch to address PR 83009.
Tested with aarch64-linux-gnu bootstrap and regtests for c, c++ and fortran.
Ran the adjusted testcase for -mabi=ilp32.
Is this OK for trunk?
Cheers,
Andre
PR target/83009: Relax strict address checking for store pair lanes
The operand constraint
Hi,
This patch series is aimed at resolving PR83009 that identified a missing
optimization opportunity for Store pair lanes. The second patch of these series
was initially reverted because it lead to a wrong codegen. This codegen was a
latent issue that was now being hit due to STP's being
19 matches
Mail list logo
