of the new impending conversion statement. This caused a skew in ABD's
pattern_stmt having the vectype of the following gimple pattern_stmt.
2024-03-06 Tejas Belagod
gcc/ChangeLog:
PR middle-end/114108
* tree-vect-patterns.cc (vect_recog_abd_pattern):
Ping!
On 3/7/24 4:14 PM, Tejas Belagod wrote:
This patch fixes a bug where vect_recog_abd_pattern called vect_convert_output
with the incorrect vecitype for the corresponding pattern_stmt.
vect_convert_output expects vecitype to be the vector form of the scalar type
of the LHS of pattern_stmt
Ping.
Thanks,
Tejas.
On 3/13/24 6:07 PM, Tejas Belagod wrote:
Ping!
On 3/7/24 4:14 PM, Tejas Belagod wrote:
This patch fixes a bug where vect_recog_abd_pattern called
vect_convert_output
with the incorrect vecitype for the corresponding pattern_stmt.
vect_convert_output expects vecitype
On 1/24/24 5:09 PM, Richard Sandiford wrote:
Tejas Belagod writes:
The target hook aarch64_class_max_nregs returns the incorrect result for 64-bit
structure modes like V31DImode or V41DFmode etc. The calculation of the nregs
is based on the size of AdvSIMD vector register for 64-bit modes
This patch fixes a bug that causes indirect calls in PAC-enabled functions
to be tailcalled incorrectly when all argument registers R0-R3 are used.
Tested on arm-none-eabi for armv8.1-m.main. OK for trunk?
2024-02-07 Tejas Belagod
PR target/113780
* gcc/config/arm.cc
On 2/7/24 11:41 PM, Richard Earnshaw (lists) wrote:
On 07/02/2024 07:59, Tejas Belagod wrote:
This patch fixes a bug that causes indirect calls in PAC-enabled functions
to be tailcalled incorrectly when all argument registers R0-R3 are used.
Tested on arm-none-eabi for armv8.1-m.main. OK for
On 2/14/24 3:55 PM, Richard Earnshaw (lists) wrote:
On 14/02/2024 09:20, Tejas Belagod wrote:
On 2/7/24 11:41 PM, Richard Earnshaw (lists) wrote:
On 07/02/2024 07:59, Tejas Belagod wrote:
This patch fixes a bug that causes indirect calls in PAC-enabled functions
to be tailcalled incorrectly
The target hook aarch64_class_max_nregs returns the incorrect result for 64-bit
structure modes like V31DImode or V41DFmode etc. The calculation of the nregs
is based on the size of AdvSIMD vector register for 64-bit modes which ought to
be UNITS_PER_VREG / 2. This patch fixes the register size.
On 6/28/24 6:18 AM, Pengxuan Zheng wrote:
This patch improves GCC’s vectorization of __builtin_popcount for aarch64 target
by adding popcount patterns for vector modes besides QImode, i.e., HImode,
SImode and DImode.
With this patch, we now generate the following for V8HI:
cnt v1.16b, v0.
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^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-pa
On 7/8/24 4:45 PM, Richard Biener wrote:
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
elev
On 7/9/24 4:22 PM, Richard Biener wrote:
On Tue, Jul 9, 2024 at 11:45 AM Tejas Belagod wrote:
On 7/8/24 4:45 PM, Richard Biener wrote:
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
On 7/10/24 2:38 PM, Richard Biener wrote:
On Wed, Jul 10, 2024 at 10:49 AM Tejas Belagod wrote:
On 7/9/24 4:22 PM, Richard Biener wrote:
On Tue, Jul 9, 2024 at 11:45 AM Tejas Belagod wrote:
On 7/8/24 4:45 PM, Richard Biener wrote:
On Mon, Jul 8, 2024 at 11:27 AM Tejas Belagod wrote
On 7/10/24 4:37 PM, Richard Biener wrote:
On Wed, Jul 10, 2024 at 12:44 PM Richard Sandiford
wrote:
Tejas Belagod writes:
On 7/10/24 2:38 PM, Richard Biener wrote:
On Wed, Jul 10, 2024 at 10:49 AM Tejas Belagod wrote:
On 7/9/24 4:22 PM, Richard Biener wrote:
On Tue, Jul 9, 2024 at 11
On 7/12/24 11:46 AM, Richard Biener wrote:
On Fri, Jul 12, 2024 at 6:17 AM Tejas Belagod wrote:
On 7/10/24 4:37 PM, Richard Biener wrote:
On Wed, Jul 10, 2024 at 12:44 PM Richard Sandiford
wrote:
Tejas Belagod writes:
On 7/10/24 2:38 PM, Richard Biener wrote:
On Wed, Jul 10, 2024 at 10
On 7/12/24 6:40 PM, Richard Biener wrote:
On Fri, Jul 12, 2024 at 3:05 PM Jakub Jelinek wrote:
On Fri, Jul 12, 2024 at 02:56:53PM +0200, Richard Biener wrote:
Padding is only an issue for very small vectors - the obvious choice is
to disallow vector types that would require any padding. I ca
On 7/15/24 12:16 PM, Tejas Belagod wrote:
On 7/12/24 6:40 PM, Richard Biener wrote:
On Fri, Jul 12, 2024 at 3:05 PM Jakub Jelinek wrote:
On Fri, Jul 12, 2024 at 02:56:53PM +0200, Richard Biener wrote:
Padding is only an issue for very small vectors - the obvious choice is
to disallow vector
On 7/15/24 6:05 PM, Richard Biener wrote:
On Mon, Jul 15, 2024 at 1:22 PM Tejas Belagod wrote:
On 7/15/24 12:16 PM, Tejas Belagod wrote:
On 7/12/24 6:40 PM, Richard Biener wrote:
On Fri, Jul 12, 2024 at 3:05 PM Jakub Jelinek wrote:
On Fri, Jul 12, 2024 at 02:56:53PM +0200, Richard Biener
On 7/17/24 4:36 PM, Richard Biener wrote:
On Wed, Jul 17, 2024 at 10:17 AM Tejas Belagod wrote:
On 7/15/24 6:05 PM, Richard Biener wrote:
On Mon, Jul 15, 2024 at 1:22 PM Tejas Belagod wrote:
On 7/15/24 12:16 PM, Tejas Belagod wrote:
On 7/12/24 6:40 PM, Richard Biener wrote:
On Fri, Jul
PING^3 on the series please.
Thanks,
Tejas.
On 7/8/24 4:25 PM, Tejas Belagod wrote:
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-Nov
On 5/30/24 6:20 PM, Richard Sandiford wrote:
Tejas Belagod writes:
The target clause in OpenMP is used to offload loop kernels to accelarator
peripeherals. target's 'map' clause is used to move data from and to the
accelarator. When the data is SVE type, it may not be suit
ct types.
doacross is mainly supported for scalars and loop iteration variables. We
diagnose cases where SVE ACLE objects are used in doacross list items.
Tejas Belagod (11):
OpenMP/PolyInt: Pass poly-int structures by address to OMP libs.
AArch64: Add test cases for SVE types in OpenMP shared
Currently poly-int type structures are passed by value to OpenMP runtime
functions for shared clauses etc. This patch improves on this by passing
around poly-int structures by address to avoid copy-overhead.
gcc/ChangeLog
* omp-low.c (use_pointer_for_field): Use pointer if the OMP data
This patch tests various shared clauses with SVE types. It also adds a test
scaffold to run OpenMP tests in under the gcc.target testsuite.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/omp/aarch64-sve-omp.exp: New scaffold.
* gcc/testsuite/gcc.target/aarch64/sve/omp/shared.c
This patch tests various OpenMP lastprivate clause with SVE object types in
various construct contexts.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/omp/lastprivate.c: New test.
---
.../gcc.target/aarch64/sve/omp/lastprivate.c | 121 ++
1 file changed, 121 insertion
This patch adds a test for ensuring threadprivate clause works for SVE type
objects.
gcc/testsuite/ChangeLog
* gcc.target/aarch64/sve/omp/threadprivate.c: New test.
---
.../aarch64/sve/omp/threadprivate.c | 44 +++
1 file changed, 44 insertions(+)
create mode 1
This patch tests if SVE object types if applied to linear clause is diagnosed
as expected.
gcc/testsuite/ChangeLog
* gcc.target/aarch64/sve/omp/linear.c: New test.
---
.../gcc.target/aarch64/sve/omp/linear.c | 33 +++
1 file changed, 33 insertions(+)
create mode 10
This patch tests simd aligned clause and their interaction with SVE types.
gcc/testsuite/ChangeLog
* gcc.target/aarch64/sve/omp/simd-aligned.c: New test.
---
.../gcc.target/aarch64/sve/omp/simd-aligned.c | 50 +++
1 file changed, 50 insertions(+)
create mode 100644 gcc/t
The target clause in OpenMP is used to offload loop kernels to accelarator
peripeherals. target's 'map' clause is used to move data from and to the
accelarator. When the data is SVE type, it may not be suitable because of
various reasons i.e. the two SVE targets may not agree on vector size or
so
This patch tests if simd uniform clause works with SVE types in simd regions.
gcc/testsuite/ChangeLog
* gcc.target/aarch64/sve/omp/simd-uniform.c: New test.
---
.../gcc.target/aarch64/sve/omp/simd-uniform.c | 71 +++
1 file changed, 71 insertions(+)
create mode 100644 gc
This patch adds a test to test depend clause and its various dependency
variations with SVE type objects.
gcc/testsuite/ChangeLog
* gcc.target/aarch64/sve/omp/depend-1.c: New test.
---
.../gcc.target/aarch64/sve/omp/depend-1.c | 223 ++
1 file changed, 223 insertions(
This patch tests user-defined reductions on various constructs with objects
of SVE type.
gcc/testsuite/ChangeLog
* gcc.target/aarch64/sve/omp/udr-sve.c: New test.
---
.../gcc.target/aarch64/sve/omp/udr-sve.c | 166 ++
1 file changed, 166 insertions(+)
create mode 10
This patch tests if SVE type objects when applied to doacross clause are
correctly diagnosed.
gcc/testsuite/ChangeLog
* gcc.target/aarch64/sve/omp/doacross.c: New test.
---
.../gcc.target/aarch64/sve/omp/doacross.c | 22 +++
1 file changed, 22 insertions(+)
create mo
On 5/30/24 6:28 PM, Richard Sandiford wrote:
Tejas Belagod writes:
Currently poly-int type structures are passed by value to OpenMP runtime
functions for shared clauses etc. This patch improves on this by passing
around poly-int structures by address to avoid copy-overhead.
gcc/ChangeLog
On 5/30/24 6:08 PM, Richard Sandiford wrote:
Tejas Belagod writes:
This patch tests various shared clauses with SVE types. It also adds a test
scaffold to run OpenMP tests in under the gcc.target testsuite.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/omp/aarch64-sve-omp.exp
PING for the series.
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/202
On 8/6/24 4:59 PM, Jakub Jelinek wrote:
On Mon, May 27, 2024 at 10:36:19AM +0530, Tejas Belagod wrote:
This patch tests various OpenMP lastprivate clause with SVE object types in
various construct contexts.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/omp/lastprivate.c: New test
Hi,
This patch replaces all inline asm implementations of vget_low_* in arm_neon.h
with optimized implementations using other neon intrinsics.
Tested with aarch64-none-elf.
OK?
Thanks,
Tejas Belagod
ARM.
2013-08-20 Tejas Belagod
gcc/
* config/aarch64/arm_neon.h: Replace all
Hi,
This patch fixes vdup_lane_* intrinsics in arm_neon.h to have the
correct lane parameter as opposed to the present '0'.
Tested on aarch64-none-elf. OK for trunk?
Thanks,
Tejas Belagod
ARM.
Changelog:
2013-09-05 Tejas Belagod
gcc/
* config/aarch64/arm_neon.h: Fi
Hi,
I've backported Ulrich's reload fix(attached)
http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01421.html
to aarch64-4.7-branch and committed it.
SendingChangeLog.aarch64
Sendingreload.c
Transmitting file data ..
Committed revision 191987.
Thanks,
Tejas.
diff --git a/gcc/rel
Ulrich Weigand wrote:
Tejas Belagod wrote:
Ulrich Weigand wrote:
The following patch implements this idea; it passes a basic regression
test on arm-linux-gnueabi. (Obviously this would need a lot more
testing on various platforms before getting into mainline ...)
Can you have a look whether
MEM having side-effects.
I would like to hear some thoughts on this.
Thanks,
Tejas Belagod
ARM.
diff --git a/gcc/recog.c b/gcc/recog.c
index 39a9dda..fa323df 100644
--- a/gcc/recog.c
+++ b/gcc/recog.c
@@ -984,6 +984,11 @@ general_operand (rtx op, enum machine_mode mode)
&& MEM_P (s
Richard Sandiford wrote:
Tejas Belagod writes:
The problem is that one reg rtx can span several hard registers.
E.g. (reg:V4SI 32) might represent one 64-bit register (no. 32),
but it might instead represent two 32-bit registers (nos. 32 and 33).
Obviously the latter's not very likel
this to
(reg:SF v0)
The attached patch helps parts of rtlanal.c make such decisions(eg.
simplify_subreg_regno).
Tested on aarch64-none-elf and aarch64_be-none-elf. OK for trunk?
Thanks,
Tejas Belagod
ARM.
Changelog:
2013-11-28 Tejas Belagod
gcc/
* config/aarch64/aarch64
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
The problem is that one reg rtx can span several hard registers.
E.g. (reg:V4SI 32) might represent one 64-bit register (no. 32),
but it might instead represent two 32-bit registers (nos. 32 and 33
H.J. Lu wrote:
On Wed, Dec 4, 2013 at 9:29 AM, Jeff Law wrote:
On 12/04/13 09:14, H.J. Lu wrote:
+
+/* { dg-final { scan-rtl-dump "deleting noop move" "combine" { target
aarch64*-*-* } } } */
Any particular reason why it doesn't work for x86?
I don't think so. I'm pretty sure Tejas is foc
Jeff Law wrote:
On 12/04/13 09:06, Tejas Belagod wrote:
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
The problem is that one reg rtx can span several hard registers.
E.g. (reg:V4SI 32) might represent one 64-bit register (no. 32),
but it
Tejas Belagod wrote:
Hi,
Currently, CANNOT_CHANGE_MODE_CLASS is too restrictive wrt the mode-changes it
allows on FPREGs - it allows none at the moment. In fact, there are many mode
changes that are safe and can be allowed. For example, in a pattern like:
(subreg:SF (reg:V4SF v0) 0
Jakub Jelinek wrote:
On Wed, Dec 04, 2013 at 08:14:43AM -0800, H.J. Lu wrote:
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/vect-nop-move.c
@@ -0,0 +1,64 @@
+/* { dg-do run } */
+/* { dg-require-effective-target vect_float } */
+/* { dg-options "-O3 -fdump-rtl-combine-details" } */
Please chan
27;t work for x86?
+/* { dg-final { cleanup-rtl-dump "combine" } } */
You also need to add
/* { dg-final { cleanup-tree-dump "vect" } } */
because all vectorizer tests dump *.vect dumps.
Here is a patch, OK to commit?
Thanks,
Tejas.
2013-12-06 Tejas Belagod
tes
Hi,
The attached patch defines TARGET_CRYPTO macro and defines builtin preprocessor
macro __ARM_FEATURE_CRYPTO.
Tested on aarch64-none-elf. OK for trunk?
Thanks,
Tejas.
Changelog
2013-12-06 Tejas Belagod
* config/aarch64/aarch64.h (TARGET_CRYPTO): New
Hi,
The attached patch adds crypto types for instruction classificiation.
Tested on aarch64-none-elf. OK for trunk?
Thanks,
Tejas
2013-12-06 Tejas Belagod
* config/arm/types.md (neon_mul_d_long, crypto_aes, crypto_sha1_xor,
crypto_sha1_fast, crypto_sha1_slow
Hi,
This patch implements support for crypto pmull.64.
Tested on aarch64-none-elf. OK for trunk?
Thanks,
Tejas.
2013-12-06 Tejas Belagod
gcc/
* config/aarch64/aarch64-builtins.c: Define builtin types for poly64_t
poly128_t.
* aarch64/aarch64-simd-builtins.def
Hi,
The attached patch implements support for crypto sha256.
Tested on aarch64-none-elf. OK for trunk?
Thanks,
Tejas.
2013-12-06 Tejas Belagod
gcc/
* config/aarch64/aarch64-simd-builtins.def: Update builtins table.
* config/aarch64/aarch64-simd.md
Hi,
The attached patch implements support for AES crypto instructions.
Tested on aarch64-none-elf. OK for trunk?
Thanks,
Tejas.
2013-12-06 Tejas Belagod
gcc/
* config/aarch64/aarch64-simd-builtins.def: Update builtins table.
* config/aarch64/aarch64-simd.md
Hi,
The attached patch implements support for SHA1 crypto insn.
Tested on aarch64-none-elf. OK for trunk?
Thanks,
Tejas.
2013-12-06 Tejas Belagod
gcc/
* config/aarch64/aarch64-simd-builtins.def: Update builtins table.
* config/aarch64/aarch64-simd.md
Kirill Yukhin wrote:
Hello,
On 05 Dec 16:40, Kirill Yukhin wrote:
On 05 Dec 05:30, H.J. Lu wrote:
Kirill, can you take a look why it doesn't work for x86?
Okay, I'll look at this.
I've looked at this. It seems that `CANNOT_CHANGE_MODE_CLASS'
is too conservative for x86.
In rtlanal.c we hav
H.J. Lu wrote:
On Tue, Dec 10, 2013 at 9:04 AM, Kirill Yukhin wrote:
On 10 Dec 08:23, H.J. Lu wrote:
What is wrong to pass the correct offset to
CANNOT_CHANGE_MODE_CLASS? Backends are free to
ignore it.
Yes, but as fas as understand this hook as a predicate
saying if it not-safe to change mo
H.J. Lu wrote:
On Tue, Dec 10, 2013 at 9:26 AM, Tejas Belagod wrote:
H.J. Lu wrote:
On Tue, Dec 10, 2013 at 9:04 AM, Kirill Yukhin
wrote:
On 10 Dec 08:23, H.J. Lu wrote:
What is wrong to pass the correct offset to
CANNOT_CHANGE_MODE_CLASS? Backends are free to
ignore it.
Yes, but as fas
On 10 December 2013 21:51, H.J. Lu wrote:
> On Tue, Dec 10, 2013 at 1:09 PM, H.J. Lu wrote:
>> On Tue, Dec 10, 2013 at 12:39 PM, Richard Henderson wrote:
>>> On 12/10/2013 10:44 AM, Richard Sandiford wrote:
Sorry, I don't understand. I never said it was invalid. I said
(subreg:SF (re
H.J. Lu wrote:
On Wed, Dec 11, 2013 at 7:49 AM, Richard Sandiford
wrote:
"H.J. Lu" writes:
On Wed, Dec 11, 2013 at 1:13 AM, Richard Sandiford
wrote:
Richard Henderson writes:
On 12/10/2013 10:44 AM, Richard Sandiford wrote:
Sorry, I don't understand. I never said it was invalid. I said
H.J. Lu wrote:
On Wed, Dec 11, 2013 at 8:26 AM, Tejas Belagod wrote:
H.J. Lu wrote:
On Wed, Dec 11, 2013 at 7:49 AM, Richard Sandiford
wrote:
"H.J. Lu" writes:
On Wed, Dec 11, 2013 at 1:13 AM, Richard Sandiford
wrote:
Richard Henderson writes:
On 12/10/2013 10:44 AM, Richard
Marcus Shawcroft wrote:
On 6 December 2013 17:36, Tejas Belagod wrote:
* gcc.target/aarch64/aes.c: New.
Add _1 on the test case file name (see http://gcc.gnu.org/wiki/TestCaseWriting)
diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
index dc56170
Marcus Shawcroft wrote:
Same comments as previous patch:
On 6 December 2013 17:36, Tejas Belagod wrote:
testsuite/
* gcc.target/aarch64/sha1.c: New.
Add _1 on the test case file name (see http://gcc.gnu.org/wiki/TestCaseWriting)
+static __inline uint32x4_t
+vsha1cq_u32
Tejas Belagod wrote:
Hi,
This patch implements support for crypto pmull.64.
Tested on aarch64-none-elf. OK for trunk?
Thanks,
Tejas.
2013-12-06 Tejas Belagod
gcc/
* config/aarch64/aarch64-builtins.c: Define builtin types for poly64_t
poly128_t.
* aarch64/aarch64
Marcus Shawcroft wrote:
On 6 December 2013 17:36, Tejas Belagod wrote:
Hi,
The attached patch implements support for crypto sha256.
Same comments as previous crypto patch.
Thanks for the review. Here is an improved patch.
Tested on aarch64-none-elf. OK for trunk?
Thanks
Tejas.
2013-12
Bingfeng Mei wrote:
Hi,
I created PR59544 and here is the patch. OK to commit?
Thanks,
Bingfeng
2013-12-18 Bingfeng Mei
PR tree-optimization/59544
* tree-vect-stmts.c (perm_mask_for_reverse): Move before
vectorizable_store. (vectorizable_store): Handle negative step.
On 28/06/14 11:25, Marc Glisse wrote:
On Mon, 23 Jun 2014, Tejas Belagod wrote:
Here is a patch that restructures neon builtins to use vector types based on
standard base types. We previously defined arm_neon.h's neon vector
types(int8x8_t) using gcc's front-end vector extensions. W
On 27/06/14 17:01, Yufeng Zhang wrote:
On 27 June 2014 16:32, Tejas Belagod wrote:
2014-06-23 Tejas Belagod
diff --git a/gcc/config/aarch64/aarch64-simd-builtin-types.def
b/gcc/config/aarch64/aarch64-simd-builtin-types.def
new file mode 100644
index 000..aa6a84e
--- /dev/null
+++ b
On 04/07/14 15:27, James Greenhalgh wrote:
On Fri, Jun 27, 2014 at 04:32:19PM +0100, Tejas Belagod wrote:
+/* Internal scalar builtin types. These types are used to support
+ neon intrinsic builtins. They are _not_ user-visible types. Therefore
+ the mangling for these types are
Hi,
The attached patch defines standard pattern name vec_extract for aarch64.
Tested on aarch64-none-elf and aarch64_be-none-elf. OK for trunk?
Thanks,
Tejas Belagod
ARM.
Changelog:
2013-11-05 Tejas Belagod
gcc/
* config/aarch64/aarch64-simd.md (vec_extract): New.diff --git a/gcc
Hi,
The attached patch adds a w -> w constraint to vec_set.
Tested on aarch64-none-elf and aarch64_be-none-elf. OK for trunk?
Thanks,
Tejas Belagod
ARM.
Changelog:
2013-11-05 Tejas Belagod
gcc/
* config/aarch64/aarch64-simd.md (vec_set): Add w -> w option to
required mode.
Also, if my understanding of Big-Endian is correct, this should be safe for
big-endian targets as well.
I've bootstrapped this on x64_64, regressed on aarch64-none-elf,
aarch64_be-none-elf.
OK for trunk?
Thanks,
Tejas Belagod
ARM.
2013-11-06 Tejas Belagod
Richard Sandiford wrote:
Tejas Belagod writes:
+ /* This is big-endian-safe because the elements are kept in target
+ memory order. So, for eg. PARALLEL element value of 2 is the same in
+ either endian-ness. */
+ if (GET_CODE (src) == VEC_SELECT
+ && REG_P (XEXP
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
+ /* This is big-endian-safe because the elements are kept in target
+ memory order. So, for eg. PARALLEL element value of 2 is the same in
+ either endian-ness. */
+ if (GET_CODE (src
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
+ /* This is big-endian-safe because the elements are kept in target
+ memory order. So, for eg. PARALLEL element value of 2 is the same in
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
+ /* This is big-endian-safe because the elements are kept in target
+ memory order. So, for eg
.2D, Vn.2D, Vn.2D.
based on what it thinks is profitable. Most of the time, the DUP is optimized
away and the scalar result is used directly. Nevertheless, the choice is given.
Tested on aarch64-none-elf and aarch64_be-none-elf. OK for trunk?
Thanks,
Tejas Belagod
ARM.
Changelog:
2013-11-15
ciated lane accesses - this is coming soon.
Thanks,
Tejas Belagod.
ARM.
Hi,
The attached patch swaps around high and low bits of the source operands of
narrow patterns for big-endian so that they end up in the correct order in the
destination.
Tested for aarch64-none-elf and aarch64_be-none-elf. OK for trunk?
Thanks,
Tejas Belagod
ARM.
2013-11-21 Tejas
Hi,
This patch fixes up the lane access patterns to be symmetric to the order in
which vectors are stored in registers.
Tested for aarch64-none-elf and aarch64_be-none-elf. OK for trunk?
Thanks,
Tejas Belagod
ARM.
2013-11-21 Tejas Belagod
gcc/
* config/aarch64/aarch64-simd.md
Hi,
The attached patch fixes the mov standard pattern name for ABI conformance
for vector modes.
Tested for aarch64-none-elf, aarch64_be-none-elf. OK for trunk?
Thanks,
Tejas Belagod
ARM.
Changelog:
2013-11-21 Tejas Belagod
gcc/
* config/aarch64/aarch64-simd.md
Hi,
The attached patch reorganizes reduc_* operations in aarch64-simd.md and fixes
up lane accesses in arm_neon.h to conform to ABI changes.
Tested for aarch64-none-elf and aarch64_be-none-elf. OK for trunk?
Thanks,
Tejas Belagod
ARM.
2013-11-21 Tejas Belagod
gcc/
* config
On 09/10/14 08:05, Michael Collison wrote:
The CLZ_DEFINED_VALUE_AT_ZERO macro is harded to return 32. For the
vector intrinsic vclz this is incorrect and should return the value
eight. The CTZ_DEFINED_VALUE_AT_ZERO has the same issue.
Tested on arm-linux-gnueabihf, arm-linux-gnueabi.
2014-10-
+(define_insn "vec_load_lanesoi_lane"
Best to prepend "aarch64_" the pattern name, IMHO, else it looks like a
standard pattern name(eg. vec_load_lanes) at first glance.
Otherwise, LGTM(but I can't approve it). Thanks for this patch.
Thanks,
Tejas.
+ [(set (match_operand:OI 0 "register_op
On 08/10/14 18:27, charles.bay...@linaro.org wrote:
From: Charles Baylis
This patch replaces the inline assembler implementations of the
vld[234](q?)_lane_* intrinsics with new versions which exploit the new builtin
functions added in patch 1.
Tested (with the rest of the patch series) with ma
Index: gcc/config/aarch64/arm_neon.h
===
--- gcc/config/aarch64/arm_neon.h (revision 216558)
+++ gcc/config/aarch64/arm_neon.h (working copy)
@@ -11765,46 +11765,271 @@ __STRUCTN (poly, 8, 4)
__STRUCTN (float, 64, 4)
#
builtin_types; t; t = TREE_CHAIN (t))
+emit_support_tinfo_1 (TREE_VALUE (t));
Regressed on aarch64-none-elf. OK for trunk?
Thanks,
Tejas.
gcc/Changelog
2014-06-23 Tejas Belagod
* config/aarch64/aarch64-builtins.c (aarch64_build_scalar_type): Remove.
(aarch64_scalar_builtin_types, aa
2014-06-23 Tejas Belagod
* config/aarch64/aarch64-builtins.c (aarch64_build_scalar_type):
Remove.
(aarch64_scalar_builtin_types, aarch64_simd_type,
aarch64_simd_types,
aarch64_mangle_builtin_scalar_type,
aarch64_mangle_builtin_vector_type
The cap value for the offset in each code model is open to debate.
All testing done with Alan's workaround
patch(https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01509.html) reversed.
bootstrapped aarch64-linux.
OK for trunk?
Thanks,
Tejas.
2014-11-14 Tejas Belagod
gcc/
* conf
On 14/11/14 08:19, Andrew Pinski wrote:
On Fri, Nov 14, 2014 at 12:12 AM, Tejas Belagod wrote:
Hi,
Following the discussion here
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02237.html, this has been
tracked down to a range-checking bug with symbol + offset style addressing
with adrp where
On 14/11/14 17:33, Marcus Shawcroft wrote:
On 14 November 2014 08:12, Tejas Belagod wrote:
2014-11-14 Tejas Belagod
gcc/
* config/aarch64/aarch64-protos.h (aarch64_classify_symbol):
Fixup prototype.
* config/aarch64/aarch64.c (aarch64_expand_mov_immediate
Ping!
On 30/04/15 10:40, Hale Wang wrote:
-Original Message-
From: Hale Wang [mailto:hale.w...@arm.com]
Sent: Monday, February 09, 2015 9:54 AM
To: Richard Earnshaw
Cc: Hale Wang; gcc-patches; Matthew Gretton-Dann
Subject: RE: [Ping^2] [PATCH, ARM, libgcc] New aeabi_idiv function for
arm
On 14/01/15 07:09, Yangfei (Felix) wrote:
On 09/12/14 08:17, Yangfei (Felix) wrote:
On 28 November 2014 at 09:23, Yangfei (Felix)
wrote:
Hi,
This patch converts vpmaxX & vpminX intrinsics to use builtin
functions
instead of the previous inline assembly syntax.
Regtested with aarch64
On 13/01/15 15:17, Christophe Lyon wrote:
__set_neon_cumulative_sat() modifies the contents on the QC flag, and
some intrinsics do so too: this patch adds the explicit dependency on
the asm statement, to avoid code reordering or removal.
When writing QC, the asm statement now has a fake input de
On 13/01/15 15:18, Christophe Lyon wrote:
* gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h (CHECK):
Add trace.
(CHECK_FP): Likewise.
(CHECK_CUMULATIVE_SAT): Likewise.
diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h
b/gcc/test
+#ifndef NO_FLOAT_VARIANT
+ VLOAD(vector, buffer, , float, f, 32, 2);
+ VLOAD(vector, buffer, q, float, f, 32, 4);
+#endif
+#ifndef NO_FLOAT_VARIANT
+ VDUP(vector2, , float, f, 32, 2, -15.5f);
+ VDUP(vector2, q, float, f, 32, 4, -14.5f);
+#endif
+
+#ifndef NO_FLOAT_VARIANT
+#define FLO
On 13/01/15 15:18, Christophe Lyon wrote:
* gcc.target/aarch64/advsimd-intrinsics/vld1_lane.c: New file.
diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1_lane.c
b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1_lane.c
new file mode 100644
index 000..168
On 13/01/15 15:18, Christophe Lyon wrote:
* gcc.target/aarch64/advsimd-intrinsics/vldX_dup.c: New file.
diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vldX_dup.c
b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vldX_dup.c
new file mode 100644
index 000..53cd
1 - 100 of 363 matches
Mail list logo
