Re: [PATCH][aarch64] Avoid tag collisions for loads on falkor

Hi Siddhesh, On 02/07/18 10:15, Siddhesh Poyarekar wrote: Hi, This is a rewrite of the tag collision avoidance patch that Kugan had written as a machine reorg pass back in February[1]. The falkor hardware prefetching system uses a combination of the source, destination and offset to decide whi

Re: [PATCH][arm] Avoid STRD with odd register for TARGET_ARM in output_move_double

Hi Christophe, On 02/07/18 13:17, Christophe Lyon wrote: On Fri, 29 Jun 2018 at 15:32, Kyrill Tkachov wrote: Hi all, In this testcase the user forces an odd register as the starting reg for a DFmode value. The output_move_double function tries to store that using an STRD instruction. But

Re: [PATCH, GCC, AARCH64] Add support for +profile extension

Hi Andre, On 09/07/18 14:20, 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 any differently given this extension, it will need to pass it on to the assembler in order to let it cor

Re: [AArch64] Use arrays and loops rather than numbered variables in aarch64_operands_adjust_ok_for_ldpstp [1/2]

Hi Jackson, On 10/07/18 09:37, Jackson Woodruff wrote: Hi all, This patch removes some duplicated code. Since this method deals with four loads or stores, there is a lot of duplicated code that can easily be replaced with smaller loops. Regtest and bootstrap OK. OK for trunk? This looks l

Re: [testsuite] Minor tweak to 4 Aarch64 testcases

Hi Eric, On 13/07/18 09:23, Eric Botcazou wrote: These 4 Aarch64 testcases use dg-xfail-if to disable themselves on ARM, while all the other equivalent testcases use dg-skip-if. The latter form is better because it doesn't unnecessarily pollute the testsuite report. Tested on arm-eabi, OK for

Re: [PATCH] [v2][aarch64] Avoid tag collisions for loads falkor

Hi Siddhesh, On 13/07/18 12:26, Siddhesh Poyarekar wrote: Hi, This is a rewrite of the tag collision avoidance patch that Kugan had written as a machine reorg pass back in February. The falkor hardware prefetching system uses a combination of the source, destination and offset to decide which

Re: [PATCH] [v3][aarch64] Avoid tag collisions for loads falkor

Hi Siddhesh, On 16/07/18 11:00, Siddhesh Poyarekar wrote: Hi, This is a rewrite of the tag collision avoidance patch that Kugan had written as a machine reorg pass back in February. The falkor hardware prefetching system uses a combination of the source, destination and offset to decide which

Re: Avoid assembler warnings from AArch64 constructor/destructor priorities

On 02/02/18 15:14, Kyrill Tkachov wrote: On 01/02/18 17:26, Joseph Myers wrote: On Thu, 1 Feb 2018, Kyrill Tkachov wrote: Hi Joseph, aarch64 maintainers, On 28/09/17 13:31, Joseph Myers wrote: Many GCC tests fail for AArch64 with current binutils because of assembler warnings of the

[PATCH][Fortran] Use MIN/MAX_EXPR for intrinsics or __builtin_fmin/max when appropriate

Hi all, This is my first Fortran patch, so apologies if I'm missing something. The current expansion of the min and max intrinsics explicitly expands the comparisons between each argument to calculate the global min/max. Some targets, like aarch64, have instructions that can calculate the min/max

Re: [PATCH][Fortran] Use MIN/MAX_EXPR for intrinsics or __builtin_fmin/max when appropriate

Hi Richard, On 17/07/18 14:27, Richard Biener wrote: On Tue, Jul 17, 2018 at 2:35 PM Kyrill Tkachov wrote: Hi all, This is my first Fortran patch, so apologies if I'm missing something. The current expansion of the min and max intrinsics explicitly expands the comparisons between

Re: [PATCH][Fortran] Use MIN/MAX_EXPR for intrinsics or __builtin_fmin/max when appropriate

Hi Thomas, On 17/07/18 16:36, Thomas Koenig wrote: Hi Kyrill, The current implementation expands to: mvar = a1; if (a2 .op. mvar || isnan (mvar)) mvar = a2; if (a3 .op. mvar || isnan (mvar)) mvar = a3; ... return mvar; That is, if one of the operands is

Re: [PATCH][Fortran] Use MIN/MAX_EXPR for intrinsics or __builtin_fmin/max when appropriate

On 18/07/18 10:44, Richard Biener wrote: On Tue, Jul 17, 2018 at 3:46 PM Kyrill Tkachov wrote: Hi Richard, On 17/07/18 14:27, Richard Biener wrote: On Tue, Jul 17, 2018 at 2:35 PM Kyrill Tkachov wrote: Hi all, This is my first Fortran patch, so apologies if I'm missing something

[PATCH][Fortran][v2] Use MIN/MAX_EXPR for min/max intrinsics

Hi all, Thank you for the feedback so far. This version of the patch doesn't try to emit fmin/fmax function calls but instead emits MIN/MAX_EXPR sequences unconditionally. I think a source of confusion in the original proposal (for me at least) was that on aarch64 (that I primarily work on) we i

Re: [PATCH][Fortran][v2] Use MIN/MAX_EXPR for min/max intrinsics

On 18/07/18 14:26, Thomas König wrote: Hi Kyrlll, Am 18.07.2018 um 13:17 schrieb Kyrill Tkachov : Thomas, Janne, would this relaxation of NaN handling be acceptable given the benefits mentioned above? If so, what would be the recommended adjustment to the nan_1.f90 test? I would be a bit

Re: [PATCH][Fortran][v2] Use MIN/MAX_EXPR for min/max intrinsics

Hi Richard, On 18/07/18 16:27, Richard Sandiford wrote: Thanks for doing this. Kyrill Tkachov writes: + calc = build_call_expr_internal_loc (input_location, ifn, type, + 2, mvar, convert (type, val)); (indentation looks off) diff --git a/gcc

Re: [PATCH, ARM] PR85434: Prevent spilling of stack protector guard's address on ARM

Hi Thomas, On 17/07/18 12:02, Thomas Preudhomme wrote: Fixed in attached patch. ChangeLog entries are unchanged: *** gcc/ChangeLog *** 2018-07-05 Thomas Preud'homme PR target/85434 * target-insns.def (stack_protect_combined_set): Define new standard pattern name. (stack_prot

Re: [PATCH] Fix a missing case of PR 21458 similar to fc6141f097056f830a412afebed8d81a9d72b696.

Hi Robert, On 24/07/18 09:48, Robert Schiele wrote: The original fix for PR 21458 was causing some issues, which were addressed to be fixed with a follow-up fix fc6141f097056f830a412afebed8d81a9d72b696. Unfortunately that follow-up fix missed one case, which is handled by this fix. Change-Id:

Re: [PATCH][GCC][AARCH64] Canonicalize aarch64 widening simd plus insns

On 24/07/18 16:12, James Greenhalgh wrote: On Thu, Jul 19, 2018 at 07:35:22AM -0500, Matthew Malcomson wrote: > Hi again. > > Providing an updated patch to include the formatting suggestions. Please try not to top-post replies, it makes the conversation thread harder to follow (reply continues

Re: [PATCH] [AArch64, Falkor] Switch to using Falkor-specific vector costs

Hi Luis, On 25/07/18 19:10, Luis Machado wrote: The adjusted vector costs give Falkor a reasonable boost in performance for FP benchmarks (both CPU2017 and CPU2006) and doesn't change INT benchmarks that much. About 0.7% for CPU2017 FP and 1.54% for CPU2006 FP. OK for trunk? The patch looks

Re: [PATCH][GCC][AARCH64] Canonicalize aarch64 widening simd plus insns

On 30/07/18 14:30, Christophe Lyon wrote: Hi, On Tue, 24 Jul 2018 at 17:39, Kyrill Tkachov wrote: On 24/07/18 16:12, James Greenhalgh wrote: On Thu, Jul 19, 2018 at 07:35:22AM -0500, Matthew Malcomson wrote: Hi again. Providing an updated patch to include the formatting suggestions

Re: [PATCH] arm: Generate correct const_ints (PR86640)

Hi Segher, On 30/07/18 14:14, Segher Boessenkool wrote: In arm_block_set_aligned_vect 8-bit constants are generated as zero- extended const_ints, not sign-extended as required. Fix that. Tamar tested the patch (see PR); no problems were found. Is this okay for trunk? The patch is okay but

Re: [PATCH] arm: Generate correct const_ints (PR86640)

Hi Segher, On 30/07/18 18:37, Segher Boessenkool wrote: On Mon, Jul 30, 2018 at 03:55:30PM +0100, Kyrill Tkachov wrote: Hi Segher, On 30/07/18 14:14, Segher Boessenkool wrote: In arm_block_set_aligned_vect 8-bit constants are generated as zero- extended const_ints, not sign-extended as

Re: [PATCH][GCC][Arm] Cleanup up reg to reg move in neon_mov.

Hi Tamar, On 23/07/18 17:52, Tamar Christina wrote: Hi All, About 13 years ago the reg-to-reg patterns were split up, before that time output_move_double could actually handle this case. After the split was done most patterns were updated except for *neon_mov which incorrectly retained reg,reg

Re: [PATCH] arm: Generate correct const_ints (PR86640)

On 31/07/18 12:38, Segher Boessenkool wrote: On Tue, Jul 31, 2018 at 09:02:56AM +0100, Kyrill Tkachov wrote: Hi Segher, On 30/07/18 18:37, Segher Boessenkool wrote: On Mon, Jul 30, 2018 at 03:55:30PM +0100, Kyrill Tkachov wrote: Hi Segher, On 30/07/18 14:14, Segher Boessenkool wrote: In

Re: [PATCH] arm: Testcase for PR86640

Hi Segher, On 31/07/18 13:14, Segher Boessenkool wrote: Hi Kyrill, As before, untested. Is this okay for trunk, or will you handle it yourself (or will someone else do it?) This is ok. Thanks, Kyrill Segher 2018-07-31 Segher Boessenkool gcc/testsuite/ PR target/86640

Re: [PATCH, ARM] PR85434: Prevent spilling of stack protector guard's address on ARM

ok to me now. Thank you for your patience and addressing my comments from before. Kyrill Best regards, Thomas On Thu, 19 Jul 2018 at 17:34, Thomas Preudhomme wrote: [Dropping Jeff Law from the list since he already commented on the middle end parts] Hi Kyrill, On Thu, 19 Jul 2018 at 12:02, K

Re: [PATCH][AArch64] Implement Armv8.5-A memory tagging (MTE) intrinsics

Hi Dennis, On 10/17/19 11:03 AM, Dennis Zhang wrote: Hi, Arm Memory Tagging Extension (MTE) is published with Armv8.5-A. It can be used for spatial and temporal memory safety detection and lightweight lock and key system. This patch enables new intrinsics leveraging MTE instructions to impleme

Re: [PATCH, GCC/ARM, 1/10] Fix -mcmse check in libgcc

Hi Mihail, On 10/23/19 10:26 AM, Mihail Ionescu wrote: [PATCH, GCC/ARM, 1/10] Fix -mcmse check in libgcc Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline Security Extensions architecture. Its purpose is to fix the check to determine whether -mcmse

Re: [PATCH, GCC/ARM, 2/10] Add command line support for Armv8.1-M Mainline

Hi Mihail, On 10/23/19 10:26 AM, Mihail Ionescu wrote: [PATCH, GCC/ARM, 2/10] Add command line support Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline Security Extensions architecture. Its purpose is to add command-line support for that new archi

Re: [PATCH 1/2] [ARM,testsuite] Skip tests incompatible with -mpure-code

Hi Christophe, On 10/18/19 2:18 PM, Christophe Lyon wrote: Hi, All these tests fail when using -mpure-code: * some force A or R profile * some use Neon * some use -fpic/-fPIC all of which are not supported by this option. OK? Hmm... I'm tempted to ask if it would be simpler to add a check f

Re: [PATCH, GCC/ARM, 2/10] Add command line support for Armv8.1-M Mainline

Hi Mihail, On 11/4/19 4:49 PM, Kyrill Tkachov wrote: Hi Mihail, On 10/23/19 10:26 AM, Mihail Ionescu wrote: > [PATCH, GCC/ARM, 2/10] Add command line support > > Hi, > > === Context === > > This patch is part of a patch series to add support for Armv8.1-M > Main

Re: [PATCH, GCC/ARM, 3/10] Save/restore FPCXTNS in nsentry functions

Hi Mihail, On 10/23/19 10:26 AM, Mihail Ionescu wrote: [PATCH, GCC/ARM, 3/10] Save/restore FPCXTNS in nsentry functions Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline Security Extensions architecture. Its purpose is to enable saving/restoring of

[PATCH][arm][1/X] Add initial support for saturation intrinsics

Hi all, This patch adds the plumbing for and an implementation of the saturation intrinsics from ACLE [1], in particular the __ssat, __usat intrinsics. These intrinsics set the Q sticky bit in APSR if an overflow occurred. ACLE allows the user to read that bit (within the same function, it's not

[PATCH][arm][3/X] Implement __smla* intrinsics (Q-setting)

Hi all, This patch implements some more Q-setting intrinsics form the SMLA* group. These can set the saturation bit on overflow in the accumulation step. Like earlier, these have non-Q-setting RTL forms as well for when the Q-bit read is not needed. Bootstrapped and tested on arm-none-linux-gn

[PATCH][arm][2/X] Implement __qadd, __qsub, __qdbl intrinsics

Hi all, This patch implements some more Q-bit-setting intrinsics from ACLE. With the plumbing from patch 1 in place they are a simple builtin->RTL affair. Bootstrapped and tested on arm-none-linux-gnueabihf. Committing to trunk. Thanks, Kyrill 2019-11-07  Kyrylo Tkachov      * config/arm/a

[PATCH][arm][6/X] Add support for __[us]sat16 intrinsics

Hi all, This last patch adds the the __ssat16 and __usat16 intrinsics that perform "clipping" to a particular bitwidth on packed SIMD values, setting the Q bit as appropriate. Bootstrapped and tested on arm-none-linux-gnueabihf. Committing to trunk. Thanks, Kyrill 2019-11-07  Kyrylo Tkachov 

[PATCH][arm][5/X] Implement Q-bit-setting SIMD32 intrinsics

Hi all, This patch implements some more Q-setting intrinsics of the multiply-accumulate variety, but these are in the SIMD32 family in that they treat their operands as packed SIMD values, but that's not important at the RTL level. Bootstrapped and tested on arm-none-linux-gnueabihf. Committ

[PATCH][arm][4/X] Add initial support for GE-setting SIMD32 intrinsics

Hi all, This patch adds in plumbing for the ACLE intrinsics that set the GE bits in APSR.  These are special SIMD instructions in Armv6 that pack bytes or halfwords into the 32-bit general-purpose registers and set the GE bits in APSR to indicate if some of the "lanes" of the result have overflow

Re: [PATCH][arm][1/X] Add initial support for saturation intrinsics

Hi Richard, On 11/9/19 12:44 PM, Richard Henderson wrote: On 11/7/19 11:26 AM, Kyrill Tkachov wrote: -;; The code sequence emitted by this insn pattern uses the Q flag, which GCC -;; doesn't generally know about, so we don't bother expanding to individual -;; instructions. It may be

Re: [PATCH][AArch64] Implement Armv8.5-A memory tagging (MTE) intrinsics

11/2019 16:40, Kyrill Tkachov wrote: Hi Dennis, On 10/17/19 11:03 AM, Dennis Zhang wrote: Hi, Arm Memory Tagging Extension (MTE) is published with Armv8.5-A. It can be used for spatial and temporal memory safety detection and lightweight lock and key system. This patch enables new intrinsics

Re: [PATCH, GCC/ARM, 4/10] Clear GPR with CLRM

Hi Mihail, On 10/23/19 10:26 AM, Mihail Ionescu wrote: [PATCH, GCC/ARM, 4/10] Clear GPR with CLRM Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline Security Extensions architecture. Its purpose is to improve code density of functions with the cmse_

Re: [PATCH, GCC/ARM, 5/10] Clear VFP registers with VSCCLRM

Hi Mihail, On 10/23/19 10:26 AM, Mihail Ionescu wrote: [PATCH, GCC/ARM, 5/10] Clear VFP registers with VSCCLRM Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline Security Extensions architecture. Its purpose is to improve code density of functions w

Re: [PATCH, GCC/ARM, 6/10] Clear GPRs inline when calling nscall function

Hi Mihail, On 10/23/19 10:26 AM, Mihail Ionescu wrote: [PATCH, GCC/ARM, 6/10] Clear GPRs inline when calling nscall function Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline Security Extensions architecture. Its purpose is to generate inline calle

Re: [PATCH, GCC/ARM, 7/10] Clear all VFP regs inline in hardfloat nscall functions

On 10/23/19 10:26 AM, Mihail Ionescu wrote: [PATCH, GCC/ARM, 7/10] Clear all VFP regs inline in hardfloat nscall functions Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline Security Extensions architecture. Its purpose is to generate inline instr

Re: [PATCH, GCC/ARM, 8/10] Do lazy store & load inline when calling nscall function

Hi Mihail, On 10/23/19 3:24 PM, Mihail Ionescu wrote: [PATCH, GCC/ARM, 8/10] Do lazy store & load inline when calling nscall function Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline Security Extensions architecture. Its purpose is to generate la

Re: [PATCH, GCC/ARM, 9/10] Call nscall function with blxns

On 10/23/19 10:26 AM, Mihail Ionescu wrote: [PATCH, GCC/ARM, 9/10] Call nscall function with blxns Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline Security Extensions architecture. Its purpose is to call functions with the cmse_nonsecure_call at

Re: [PATCH, GCC/ARM, 10/10] Enable -mcmse

On 10/23/19 10:26 AM, Mihail Ionescu wrote: [PATCH, GCC/ARM, 10/10] Enable -mcmse Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline Security Extensions architecture. Its purpose is to enable the -mcmse option now that support for Armv8.1-M Securit

Re: [PATCH 2/2] [ARM] Add support for -mpure-code in thumb-1 (v6m)

Hi Christophe, On 10/18/19 2:18 PM, Christophe Lyon wrote: Hi, This patch extends support for -mpure-code to all thumb-1 processors, by removing the need for MOVT. Symbol addresses are built using upper8_15, upper0_7, lower8_15 and lower0_7 relocations, and constants are built using sequences

Re: [PATCH][arm][1/X] Add initial support for saturation intrinsics

Hi Christophe, On 11/12/19 10:29 AM, Christophe Lyon wrote: On Thu, 7 Nov 2019 at 11:26, Kyrill Tkachov wrote: Hi all, This patch adds the plumbing for and an implementation of the saturation intrinsics from ACLE [1], in particular the __ssat, __usat intrinsics. These intrinsics set the Q

Re: [PATCH][AArch64] Implement Armv8.5-A memory tagging (MTE) intrinsics

On 11/12/19 3:50 PM, Dennis Zhang wrote: Hi Kyrill, On 12/11/2019 09:40, Kyrill Tkachov wrote: Hi Dennis, On 11/7/19 1:48 PM, Dennis Zhang wrote: Hi Kyrill, I have rebased the patch on top of current truck. For resolve_overloaded, I redefined my memtag overloading function to fit the

[PATCH][wwwdocs] GCC 10 changes.html for arm and aarch64

Hi all, This patch adds initial entries for notable features that went in to GCC 10 on the arm and aarch64 front. The list is by no means complete so if you'd like your contribution called please shout or post a follow-up patch. It is, nevertheless, a decent start at the relevant sections in c

Re: [Patch 0/X] HWASAN v3

On 1/8/20 11:26 AM, Matthew Malcomson wrote: Hi everyone, I'm writing this email to summarise & publicise the state of this patch series, especially the difficulties around approval for GCC 10 mentioned on IRC. The main obstacle seems to be that no maintainer feels they have enough knowledge

Re: [GCC][PATCH][ARM] Add Bfloat16_t scalar type, vector types and machine modes to ARM back-end [1/2]

Hi Stam, On 1/10/20 6:45 PM, Stam Markianos-Wright wrote: Hi all, This is a respin of patch: https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01448.html which has now been split into two (similar to the Aarch64 version). This is patch 1 of 2 and adds Bfloat type support to the ARM back-end. It

Re: [GCC][PATCH][ARM] Add Bfloat16_t scalar type, vector types and machine modes to ARM back-end [2/2]

Hi Stam, On 1/10/20 6:47 PM, Stam Markianos-Wright wrote: Hi all, This patch is part 2 of Bfloat16_t enablement in the ARM back-end. This new type is constrained using target hooks TARGET_INVALID_CONVERSION, TARGET_INVALID_UNARY_OP, TARGET_INVALID_BINARY_OP so that it may only be used throug

Re: [PATCH 2/2] [ARM] Add support for -mpure-code in thumb-1 (v6m)

Hi Christophe, On 12/17/19 3:31 PM, Kyrill Tkachov wrote: On 12/17/19 2:33 PM, Christophe Lyon wrote: On Tue, 17 Dec 2019 at 11:34, Kyrill Tkachov wrote: Hi Christophe, On 11/18/19 9:00 AM, Christophe Lyon wrote: On Wed, 13 Nov 2019 at 15:46, Christophe Lyon wrote: On Tue, 12 Nov 2019

Re: [PATCH, GCC/ARM, 4/10] Clear GPR with CLRM

On 12/18/19 1:26 PM, Mihail Ionescu wrote: Hi Kyrill, On 12/17/2019 10:26 AM, Kyrill Tkachov wrote: Hi Mihail, On 12/16/19 6:29 PM, Mihail Ionescu wrote: Hi Kyrill, On 11/12/2019 09:55 AM, Kyrill Tkachov wrote: Hi Mihail, On 10/23/19 10:26 AM, Mihail Ionescu wrote: [PATCH, GCC/ARM, 4

Re: [PATCH 2/2] [ARM] Add support for -mpure-code in thumb-1 (v6m)

On 1/14/20 1:50 PM, Christophe Lyon wrote: On Mon, 13 Jan 2020 at 14:49, Kyrill Tkachov wrote: Hi Christophe, On 12/17/19 3:31 PM, Kyrill Tkachov wrote: On 12/17/19 2:33 PM, Christophe Lyon wrote: On Tue, 17 Dec 2019 at 11:34, Kyrill Tkachov wrote: Hi Christophe, On 11/18/19 9:00 AM

Re: [PATCH][AARCH64] Set jump-align=4 for neoversen1

Hi Richard, Wilco, On 1/17/20 8:43 AM, Richard Sandiford wrote: Wilco Dijkstra writes: > Testing shows the setting of 32:16 for jump alignment has a significant codesize > cost, however it doesn't make a difference in performance. So set jump-align > to 4 to get 1.6% codesize improvement. I

Re: [PATCH, GCC/ARM, 1/2] Add support for ASRL(reg) and LSLL(reg) instructions for Armv8.1-M Mainline

On 12/18/19 1:23 PM, Mihail Ionescu wrote: Hi Kyrill, On 12/11/2019 05:50 PM, Kyrill Tkachov wrote: > Hi Mihail, > > On 11/14/19 1:54 PM, Mihail Ionescu wrote: >> Hi, >> >> This patch adds the new scalar shift instructions for Armv8.1-M >> Mainline to

Re: [PING][PATCH][GCC][ARM] Arm generates out of range conditional branches in Thumb2 (PR91816)

Hi Stam, On 1/8/20 3:18 PM, Stam Markianos-Wright wrote: On 12/10/19 5:03 PM, Kyrill Tkachov wrote: Hi Stam, On 11/15/19 5:26 PM, Stam Markianos-Wright wrote: Pinging with more correct maintainers this time :) Also would need to backport to gcc7,8,9, but need to get this approved first

Re: [PING][PATCH][GCC][ARM] Arm generates out of range conditional branches in Thumb2 (PR91816)

On 1/30/20 2:42 PM, Stam Markianos-Wright wrote: On 1/28/20 10:35 AM, Kyrill Tkachov wrote: Hi Stam, On 1/8/20 3:18 PM, Stam Markianos-Wright wrote: On 12/10/19 5:03 PM, Kyrill Tkachov wrote: Hi Stam, On 11/15/19 5:26 PM, Stam Markianos-Wright wrote: Pinging with more correct

Re: [GCC][PATCH][AArch32] ACLE intrinsics bfloat16 vmmla and vfma for AArch32 AdvSIMD

Hi Delia, On 1/28/20 4:44 PM, Delia Burduv wrote: Ping. *From:* Delia Burduv *Sent:* 22 January 2020 17:26 *To:* gcc-patches@gcc.gnu.org *Cc:* ni...@redhat.com ; Richard Earnshaw ; Ramana Radhakrishnan ; Kyrylo Tkachov

Re: [GCC][PATCH][ARM] Regenerate arm-tables.opt for Armv8.1-M patch

On 2/3/20 5:18 PM, Mihail Ionescu wrote: Hi all, I've regenerated arm-tables.opt in config/arm to replace the improperly generated arm-tables.opt file from "[PATCH, GCC/ARM, 2/10] Add command line support for Armv8.1-M Mainline" (9722215a027b68651c3c7a8af9204d033197e9c0). 2020-02-03  Mihai

Re: [GCC][PATCH][ARM] Set profile to M for Armv8.1-M

On 2/4/20 1:49 PM, Christophe Lyon wrote: On Mon, 3 Feb 2020 at 18:20, Mihail Ionescu wrote: > > Hi, > > We noticed that the profile for armv8.1-m.main was not set in arm-cpus.in > , which led to TARGET_ARM_ARCH_PROFILE and _ARM_ARCH_PROFILE not being > defined properly. > > > > gcc/ChangeL

Re: [Pingx3][GCC][PATCH][ARM]Add ACLE intrinsics for dot product (vusdot - vector, vdot - by element) for AArch32 AdvSIMD ARMv8.6 Extension

Hi Stam, On 2/10/20 1:35 PM, Stam Markianos-Wright wrote: On 2/3/20 11:20 AM, Stam Markianos-Wright wrote: > > > On 1/27/20 3:54 PM, Stam Markianos-Wright wrote: >> >> On 1/16/20 4:05 PM, Stam Markianos-Wright wrote: >>> >>> >>> On 1/10/20 6:48 PM, Stam Markianos-Wright wrote: O

[PATCH][gas] Implement .cfi_negate_ra_state directive

Hi all, This patch implements the .cfi_negate_ra_state to be consistent with LLVM (https://reviews.llvm.org/D50136). The relevant DWARF code DW_CFA_AARCH64_negate_ra_state is multiplexed on top of DW_CFA_GNU_window_save, as per https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00753.html I believe

Re: [PATCH][gas] Implement .cfi_negate_ra_state directive

Sorry, wrong list address from my side, please ignore. Kyrill On 12/5/19 10:59 AM, Kyrill Tkachov wrote: Hi all, This patch implements the .cfi_negate_ra_state to be consistent with LLVM (https://reviews.llvm.org/D50136). The relevant DWARF code DW_CFA_AARCH64_negate_ra_state is multiplexed

Re: [PING][PATCH][GCC][ARM] Arm generates out of range conditional branches in Thumb2 (PR91816)

Hi Stam, On 11/15/19 5:26 PM, Stam Markianos-Wright wrote: Pinging with more correct maintainers this time :) Also would need to backport to gcc7,8,9, but need to get this approved first! Sorry for the delay. Thank you, Stam Forwarded Message Subject: Re: [PATCH][GCC][

Re: Ping: [GCC][PATCH] Add ARM-specific Bfloat format support to middle-end

Hi all, On 12/11/19 9:41 AM, Stam Markianos-Wright wrote: On 12/11/19 3:48 AM, Jeff Law wrote: > On Mon, 2019-12-09 at 13:40 +, Stam Markianos-Wright wrote: >> >> On 12/3/19 10:31 AM, Stam Markianos-Wright wrote: >>> >>> On 12/2/19 9:27 PM, Joseph Myers wrote: On Mon, 2 Dec 2019, Jeff

Re: [PATCH, GCC/ARM, 1/2] Add support for ASRL(reg) and LSLL(reg) instructions for Armv8.1-M Mainline

Hi Mihail, On 11/14/19 1:54 PM, Mihail Ionescu wrote: Hi, This patch adds the new scalar shift instructions for Armv8.1-M Mainline to the arm backend. This patch is adding the following instructions: ASRL (reg) LSLL (reg) Sorry for the delay, very busy time for GCC development :( Change

Re: [PATCH, GCC/ARM, 2/2] Add support for ASRL(imm), LSLL(imm) and LSRL(imm) instructions for Armv8.1-M Mainline

Hi Mihail, On 11/14/19 1:54 PM, Mihail Ionescu wrote: Hi, This is part of a series of patches where I am trying to add new instructions for Armv8.1-M Mainline to the arm backend. This patch is adding the following instructions: ASRL (imm) LSLL (imm) LSRL (imm) ChangeLog entry are as follow:

Re: [PATCH][ARM][GCC][0/x]: Support for MVE ACLE intrinsics.

Hi Srinath, On 11/14/19 7:12 PM, Srinath Parvathaneni wrote: Hello, This patches series is to support Arm MVE ACLE intrinsics. Please refer to Arm reference manual [1] and MVE intrinsics [2] for more details. Please refer to Chapter 13 MVE ACLE [3] for MVE intrinsics concepts. This patch se

Re: [PATCH 3/X] [libsanitizer] Add option to bootstrap using HWASAN

Hi Matthew, Martin is the authority on this but I have a small comment inline... On 12/12/19 3:19 PM, Matthew Malcomson wrote: This is an analogous option to --bootstrap-asan to configure.  It allows bootstrapping GCC using HWASAN. For the same reasons as for ASAN we have to avoid using the HW

Re: [PATCH] [AARCH64] Improve vector generation cost model

Hi Andrew, On 3/15/19 1:18 AM, apin...@marvell.com wrote: From: Andrew Pinski Hi,   On OcteonTX2, ld1r and ld1 (with a single lane) are split into two different micro-ops unlike most other targets. This adds three extra costs to the cost table: ld1_dup: used for "ld1r {v0.4s}, [x0]" merge_dup:

Re: [PATCH, GCC/ARM, 2/10] Add command line support for Armv8.1-M Mainline

Hi Mihail, On 12/16/19 6:28 PM, Mihail Ionescu wrote: Hi Kyrill On 11/06/2019 03:59 PM, Kyrill Tkachov wrote: Hi Mihail, On 11/4/19 4:49 PM, Kyrill Tkachov wrote: Hi Mihail, On 10/23/19 10:26 AM, Mihail Ionescu wrote: > [PATCH, GCC/ARM, 2/10] Add command line support >

Re: [PATCH, GCC/ARM, 3/10] Save/restore FPCXTNS in nsentry functions

Hi Mihail, On 12/16/19 6:29 PM, Mihail Ionescu wrote: Hi Kyrill, On 11/06/2019 04:12 PM, Kyrill Tkachov wrote: Hi Mihail, On 10/23/19 10:26 AM, Mihail Ionescu wrote: [PATCH, GCC/ARM, 3/10] Save/restore FPCXTNS in nsentry functions Hi, === Context === This patch is part of a patch series

Re: [PATCH, GCC/ARM, 4/10] Clear GPR with CLRM

Hi Mihail, On 12/16/19 6:29 PM, Mihail Ionescu wrote: Hi Kyrill, On 11/12/2019 09:55 AM, Kyrill Tkachov wrote: Hi Mihail, On 10/23/19 10:26 AM, Mihail Ionescu wrote: [PATCH, GCC/ARM, 4/10] Clear GPR with CLRM Hi, === Context === This patch is part of a patch series to add support for

Re: [PATCH 2/2] [ARM] Add support for -mpure-code in thumb-1 (v6m)

Hi Christophe, On 11/18/19 9:00 AM, Christophe Lyon wrote: On Wed, 13 Nov 2019 at 15:46, Christophe Lyon wrote: > > On Tue, 12 Nov 2019 at 12:13, Richard Earnshaw (lists) > wrote: > > > > On 18/10/2019 14:18, Christophe Lyon wrote: > > > +  bool not_supported = arm_arch_notm || flag_pic ||

Re: [PATCH 2/2] [ARM] Add support for -mpure-code in thumb-1 (v6m)

On 12/17/19 2:33 PM, Christophe Lyon wrote: On Tue, 17 Dec 2019 at 11:34, Kyrill Tkachov wrote: Hi Christophe, On 11/18/19 9:00 AM, Christophe Lyon wrote: On Wed, 13 Nov 2019 at 15:46, Christophe Lyon wrote: On Tue, 12 Nov 2019 at 12:13, Richard Earnshaw (lists) wrote: On 18/10/2019 14

Re: [PATCH][AArch64] Fixup core tunings

Hi Wilco, On 12/17/19 4:03 PM, Wilco Dijkstra wrote: Hi Richard, > This changelog entry is inadequate.  It's also not in the correct style. > > It should say what has changed, not just that it has changed. Sure, but there is often no useful space for that. We should auto generate changelogs if

Re: [PATCH][GCC][arm] Add CLI and multilib support for Armv8.1-M Mainline MVE extensions

Hi Mihail, On 11/8/19 4:52 PM, Mihail Ionescu wrote: Hi, This patch adds CLI and multilib support for Armv8.1-M MVE to the Arm backend. Two new option added for v8.1-m.main: "+mve" for integer MVE instructions only and "+mve.fp" for both integer and single-precision/half-precision floating-p

Re: [PATCH, GCC/ARM, 9/10] Call nscall function with blxns

On 12/18/19 1:38 PM, Mihail Ionescu wrote: Hi, On 11/12/2019 10:23 AM, Kyrill Tkachov wrote: On 10/23/19 10:26 AM, Mihail Ionescu wrote: [PATCH, GCC/ARM, 9/10] Call nscall function with blxns Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline

Re: [PATCH][GCC][arm] Add CLI and multilib support for Armv8.1-M Mainline MVE extensions

On 12/18/19 5:00 PM, Mihail Ionescu wrote: Hi Kyrill, On 12/18/2019 02:13 PM, Kyrill Tkachov wrote: > Hi Mihail, > > On 11/8/19 4:52 PM, Mihail Ionescu wrote: >> Hi, >> >> This patch adds CLI and multilib support for Armv8.1-M MVE to the Arm >> backend. >&g

Re: [PATCH][ARM][GCC][1/x]: MVE ACLE intrinsics framework patch.

On 11/14/19 7:12 PM, Srinath Parvathaneni wrote: Hello, This patch creates the required framework for MVE ACLE intrinsics. The following changes are done in this patch to support MVE ACLE intrinsics. Header file arm_mve.h is added to source code, which contains the definitions of MVE ACLE

Re: [PATCH][ARM][GCC][2/x]: MVE ACLE intrinsics framework patch.

Hi Srinath, On 11/14/19 7:12 PM, Srinath Parvathaneni wrote: Hello, This patch is part of MVE ACLE intrinsics framework. This patches add support to update (read/write) the APSR (Application Program Status Register) register and FPSCR (Floating-point Status and Control Register) register for

Re: [PATCH][ARM][GCC][4/x]: MVE ACLE vector interleaving store intrinsics.

On 11/14/19 7:12 PM, Srinath Parvathaneni wrote: Hello, This patch supports MVE ACLE intrinsics vst4q_s8, vst4q_s16, vst4q_s32, vst4q_u8, vst4q_u16, vst4q_u32, vst4q_f16 and vst4q_f32. In this patch arm_mve_builtins.def file is added to the source code in which the builtins for MVE ACLE i

Re: [PATCH][ARM][GCC][3/x]: MVE ACLE intrinsics framework patch.

Hi Srinath, On 11/14/19 7:12 PM, Srinath Parvathaneni wrote: Hello, This patch is part of MVE ACLE intrinsics framework. The patch supports the use of emulation for the double-precision arithmetic operations for MVE. This changes are to support the MVE ACLE intrinsics which operates on vect

Re: [PATCH][ARM][GCC][1/1x]: Patch to support MVE ACLE intrinsics with unary operand.

Hi Srinath, On 11/14/19 7:12 PM, Srinath Parvathaneni wrote: Hello, This patch supports MVE ACLE intrinsics vcvtq_f16_s16, vcvtq_f32_s32, vcvtq_f16_u16, vcvtq_f32_u32n vrndxq_f16, vrndxq_f32, vrndq_f16, vrndq_f32, vrndpq_f16, vrndpq_f32, vrndnq_f16, vrndnq_f32, vrndmq_f16, vrndmq_f32, vrndaq_

Re: [PATCH][ARM][GCC][2/1x]: MVE intrinsics with unary operand.

Hi Srinath, On 11/14/19 7:13 PM, Srinath Parvathaneni wrote: Hello, This patch supports following MVE ACLE intrinsics with unary operand. vmvnq_n_s16, vmvnq_n_s32, vrev64q_s8, vrev64q_s16, vrev64q_s32, vcvtq_s16_f16, vcvtq_s32_f32, vrev64q_u8, vrev64q_u16, vrev64q_u32, vmvnq_n_u16, vmvnq_n_u3

Re: [PATCH][ARM][GCC][4/1x]: MVE intrinsics with unary operand.

Hi Srinath, On 11/14/19 7:13 PM, Srinath Parvathaneni wrote: Hello, This patch supports following MVE ACLE intrinsics with unary operand. vctp16q, vctp32q, vctp64q, vctp8q, vpnot. Please refer to M-profile Vector Extension (MVE) intrinsics [1]  for more details. [1] https://developer.arm.co

Re: [PATCH][ARM][GCC][1/2x]: MVE intrinsics with binary operands.

Hi Srinath, On 11/14/19 7:13 PM, Srinath Parvathaneni wrote: Hello, This patch supports following MVE ACLE intrinsics with binary operand. vsubq_n_f16, vsubq_n_f32, vbrsrq_n_f16, vbrsrq_n_f32, vcvtq_n_f16_s16, vcvtq_n_f32_s32, vcvtq_n_f16_u16, vcvtq_n_f32_u32, vcreateq_f16, vcreateq_f32. Pl

Re: [PATCH][Arm] Enable CLI for Armv8.6-a: armv8.6-a, i8mm and bf16

Hi Dennis, On 12/12/19 5:30 PM, Dennis Zhang wrote: Hi all, On 22/11/2019 14:33, Dennis Zhang wrote: > Hi all, > > This patch is part of a series adding support for Armv8.6-A features. > It enables options including -march=armv8.6-a, +i8mm and +bf16. > The +i8mm and +bf16 features are optional

Re: [PATCH] AARCH64: Add Qualcomnm oryon-1 core

Hi Andrew, On Fri, May 3, 2024 at 8:50 PM Andrew Pinski wrote: > This patch adds Qualcomm's new oryon-1 core; this is enough > to recongize the core and later on will add the tuning structure. > > gcc/ChangeLog: > > * config/aarch64/aarch64-cores.def (oryon-1): New entry. > * con

Re: [PATCH 1/4]AArch64: convert several predicate patterns to new compact syntax

Hi Tamar, On Wed, 15 May 2024 at 11:28, Tamar Christina wrote: > Hi All, > > This converts the single alternative patterns to the new compact syntax > such > that when I add the new alternatives it's clearer what's being changed. > > Note that this will spew out a bunch of warnings from geninsn

Re: [PATCH] AArch64: Add ACLE MOPS support

Hi Wilco, On Fri, May 31, 2024 at 6:38 PM Wilco Dijkstra wrote: > Hi Richard, > > > I think this should be in a push_options/pop_options block, as for other > > intrinsics that require certain features. > > But then the intrinsic would always be defined, which is contrary to what > the > ACLE sp

RE: [PATCH][ARM] Improve cond_exec opportunities for immediate shifts for -mrestrict-it

> On 09/09/13 17:32, Kyrylo Tkachov wrote: > > Hi all, > > > > Shift operations with an immediate can generate a 16-bit encoding when > > the immediate is 5-bit wide, i.e. in the range [0-31]. Therefore we > > can use them in IT blocks even with the -mrestrict-it rules. > > > > I decided to reuse t

[PATCH][ARM] set "type" attribute properly in arm_cmpsi_insn, cleanup

Hi all, This patch splits the r/rI alternative in arm_cmpsi_insn so as to better specify the "type" attribute. Also, the predicable_short_it attribute is set properly to conform to the -mrestrict-it rules. A nearby pattern has a redundant "%?" removed. Tested arm-none-eabi on a model and bootst

[PATCH][ARM][testsuite] Add effective target check for arm conditional execution

Hi all, gcc.target/arm/minmax_minus.c is really only valid when we have conditional execution available, that is non Thumb1-only targets. I've added an effective target check for that and used it in the test so that it does not get run and give a false negative when testing Thumb1 targets. O

[PATCH] Fix FAIL: g++.dg/debug/ra1.C on arm

Hi all, The test g++.dg/debug/ra1.C now gives an extra warning on arm: "warning: width of 'tree_base::code' exceeds its type [enabled by default]" which causes the test to "fail". This patch adds -fno-short-enums to it to fix the warning for targets with short enums (including arm) Tested to

Re: [PATCH][Resend][tree-optimization] Fix PR58088

Ping. On 09/09/13 10:56, Kyrylo Tkachov wrote: [Resending, since I was away and not pinging it] Hi all, In PR58088 the constant folder goes into an infinite recursion and runs out of stack space because of two conflicting optimisations: (X * C1) & C2 plays dirty when nested inside an IOR expr

  1   2   3   4   5   6   7   8   9   10   >