RE: Should ARMv8-A generic tuning default to -moutline-atomics

Hi Florian, > -Original Message- > From: Gcc On Behalf Of Florian Weimer via Gcc > Sent: 29 April 2020 13:33 > To: gcc@gcc.gnu.org > Cc: nmeye...@amzn.com > Subject: Should ARMv8-A generic tuning default to -moutline-atomics > > Distributions are receiving requests to build things with >

RE: Should ARMv8-A generic tuning default to -moutline-atomics

Hi Michael, > -Original Message- > From: Gcc On Behalf Of Michael Matz > Sent: 30 April 2020 12:10 > To: Florian Weimer > Cc: gcc@gcc.gnu.org; nmeye...@amzn.com > Subject: Re: Should ARMv8-A generic tuning default to -moutline-atomics > > Hello, > > On Wed, 29 Apr 2020, Florian Weimer

RE: GCC 10.0.1 Status Report (2019-04-30)

> -Original Message- > From: Gcc On Behalf Of Jakub Jelinek via Gcc > Sent: 30 April 2020 18:11 > To: gcc@gcc.gnu.org > Subject: GCC 10.0.1 Status Report (2019-04-30) > > Status > == > > We have reached zero P1 regressions today and releases/gcc-10 branch has > been created; GCC

Re: Right way to represent flag-setting arithmetic instructions in MD files

On 10/03/17 10:38, Jakub Jelinek wrote: On Fri, Mar 10, 2017 at 10:10:34AM +, Kyrill Tkachov wrote: Hi all, Some (many?) targets have instructions that perform an arithmetic operation and set the condition flags based on the result. For example, on aarch64, we have instructions like ADDS,

cond_exec no-ops in RTL optimisations

Hi everyone, While working with some splitters I noticed that the RTL optimisation passes do not optimise away a no-op wrapped in a cond_exec. So for example, if my splitter generates something like: (cond_exec (lt:SI (reg:CC CC_REGNUM) (const_int 0)) (set (match_dup 1)

RE: Recognizing loop pattern

> -Original Message- > From: Gcc On Behalf Of Stefan Schulze > Frielinghaus via Gcc > Sent: 26 October 2020 09:58 > To: gcc@gcc.gnu.org > Subject: Recognizing loop pattern > > I'm trying to detect loops of the form > > while (*x != y) > ++x; > > which mimic the behaviour of fun

RE: How about providing an interface to fusing instructions via scheduling

Hi, > -Original Message- > From: Gcc On Behalf > Of gengqi via Gcc > Sent: 03 September 2021 11:56 > To: gcc@gcc.gnu.org > Subject: How about providing an interface to fusing instructions via > scheduling > > When I was adding pipeline to my backend, some instructions needed to be > fuse

Ordering function layout for locality follow-up

Hello, Thanks to those that attended the IPA/LTO BoF at GNU Cauldron over the weekend and gave us feedback on teaching GCC to optimize for layout locality in the callgraph I’d like to follow-up on the previous work in the area that Honza mentioned to see if we can reuse some of it or follow its

Re: C Standard Libraries

> On 15 Oct 2024, at 18:09, Bryon Quackenbush via Gcc wrote: > > External email: Use caution opening links or attachments > > > Does anyone know where in the GCC hierarchy that I can find implementation > code for standard C library functions like fgetc / fputs, etc, or would > that be outsi

Re: Christophe Lyon as MVE reviewer for the AArch32 (arm) port.

> On 26 Sep 2024, at 19:22, Ramana Radhakrishnan > wrote: > > External email: Use caution opening links or attachments > > > I am pleased to announce that the GCC Steering Committee has appointed > Christophe Lyon as a MVE Reviewer for the AArch32 port. > > Please join me in congratulating

Re: [RFC][AArch64] Defining lrotm3 optabs for SVE modes for TARGET_SVE2?

> On 18 Oct 2024, at 19:46, Richard Sandiford wrote: > > Kyrylo Tkachov writes: >> Hello, >> >> I’ve been optimizing various code sequences relating to vector rotates >> recently. >> I ended up proposing we expand the vector-rotate-by-immediate op

RFC: IPA/LTO: Ordering functions for locality

Hi all, I'd like to continue the discussion on teaching GCC to optimise code layout for locality between callees and callers. This is work that we've been doing at NVIDIA, primarily Prachi Godbole (CC'ed) and myself. This is a follow-up to the discussion we had at GNU Cauldron at the IPA/LTO BoF [

[PATCH] PR target/117449: Restrict vector rotate match and split to pre-reload

would then match the insn again and try to split it. So do a clean split pre-reload and avoid going down this path post-reload by restricting the insn_and_split to can_create_pseudo_p (). Bootstrapped and tested on aarch64-none-linux. Pushing to trunk. Thanks, Kyrill Signed-off-by: Kyrylo Tkachov gcc

[RFC][AArch64] Defining lrotm3 optabs for SVE modes for TARGET_SVE2?

Hello, I’ve been optimizing various code sequences relating to vector rotates recently. I ended up proposing we expand the vector-rotate-by-immediate optab rotlm3 for the Advanced SIMD (Neon) modes here: https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665635.html This expands to a ROTATE RT

Re: aarch64 built-in SIMD types

Hi Tom, > On 24 Feb 2025, at 20:40, Tom Kacvinsky via Gcc wrote: > > Hi all, > > I am trying to find where the aarch64 SIMD built in types are defined in > GCC. > For instance, __Int8x8_t. I see some code in gcc/config/aarch64 for these, > but > then it goes deeper into internals of gcc that I

Re: GCC used to store pointers in FP registers on aarch64

Hi Attila, > On 24 Feb 2025, at 10:46, Attila Szegedi via Gcc wrote: > > Hi folks, > > I'm looking for a bit of a historic context for a fun GCC behavior we > stumbled across. For... reasons we build some of our binaries using an > older version of GCC (8.3.1, yes, we'll be upgrading soon, and