Re: Questions about macro fusion pass

Hau Hsu via Gcc writes: > Hi, > > I have a question about GCC's macro fusion pass. > In the GCC internals doc, there is a hook for scheduling: > TARGET_SCHED_MACRO_FUSION_PAIR_P > > I

Re: Questions about uses of (define_subst ...)

Hi, Sorry for the slow reply, didn't see this till now. Benoit Dinechin via Gcc writes: > Hello, > > I use (define_subst ...) in a way that solves my .md factoring > problems but I wonder if this use is expected and if will be > maintained / documented in the future. > > Target is a 64-bit core

Should we move the --param documention to gccint?

We changed one of the AArch64-specific --params for GCC 14. Unfortunately, it seems that a lot of people were relying on the previous behaviour. Every --param is documented in the user-facing manual, so it's not surprising that people picked it up. The documentation of --param itself starts with:

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

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 optab rotlm3 for > the Advanced SIMD (Neon) modes here: > https://gcc.gnu.org/pipermail/gcc-patches/2024-October/6

Re: Alex Coplan appointed maintainer of AArch64 pair fusion pass and pair-fusion pass.

Ramana Radhakrishnan via Gcc writes: > I am pleased to announce that the GCC Steering Committee has appointed > Alex Coplan as a maintainer for the AArch64 load / store pair fusion > pass. > > In addition the steering committee has also appointed him as > maintainer for the Pair Fusion pass in the

Re: Proposed new pass to optimise mode register assignments

Jeff Law writes: > On 9/7/24 1:09 AM, Richard Biener wrote: >> >> >>> Am 06.09.2024 um 17:38 schrieb Andrew Carlotti : >>> >>> Hi, >>> >>> I'm working on optimising assignments to the AArch64 Floating-point Mode >>> Register (FPMR), as part of our FP8 enablement work. Claudio has already >>> i

Re: Late combine & mode switch

Sorry for the slow response. Xi Ruoyao writes: > Hi Richard, > > When I hack the LoongArch backend I notice something like > > slli.d $r4, $r4, 2 > add.w $r4, $r4, $r5 > > Or > > (set (reg:DI 4) (ashift:DI (reg:DI 4) (const_int 2)) > (set (reg:DI 4) > (sign_extend:DI (add:SI (reg:SI 4) (reg:

Re: insn attributes: Support blocks of C-code?

Georg-Johann Lay writes: > [...] > Am 13.07.24 um 13:44 schrieb Richard Sandiford: >> Georg-Johann Lay writes: >>> diff --git a/gcc/read-md.h b/gcc/read-md.h >>> index 9703551a8fd..ae10b651de1 100644 >>> --- a/gcc/read-md.h >>> +++ b/gcc/read-md.h

Re: Insn combine trying (ior:HI (clobber:HI (const_int 0)))

Georg-Johann Lay writes: > In a test case I see insn combine trying to match such > expressions, which do not make any sense to me, like: > > Trying 2 -> 7: > 2: r45:HI=r48:HI >REG_DEAD r48:HI > 7: {r47:HI=r45:HI|r46:PSI#0;clobber scratch;} >REG_DEAD r46:PSI >REG_

Re: insn attributes: Support blocks of C-code?

Georg-Johann Lay writes: > So I had that situation where in an insn attribute, providing > a block of code (rather than just an expression) would be > useful. > > Expressions can provided by means of symbol_ref, like in > > (set (attr "length") > (symbol_ref ("1 + GET_MODE_SIZE (mode)"))) >

Re: Help with vector cost model

Andrew Pinski writes: > I need some help with the vector cost model for aarch64. > I am adding V2HI and V4QI mode support by emulating it using the > native V4HI/V8QI instructions (similarly to mmx as SSE is done). The > problem is I am running into a cost model issue with > gcc.target/aarch64/pr9

Re: md: define_code_attr / define_mode_attr: Default value?

Georg-Johann Lay writes: > Is it possible to specify a default value in > define_code_attr resp. define_mode_attr ? > > I had a quick look at read-rtl, and it seem to be not the case. Yeah, that's right. I'd assumed the attributes would be used in cases where an active choice has to be made for

Re: [RFC] MAINTAINERS: require a BZ account field

Sam James writes: > Richard Sandiford writes: > >> Sam James via Gcc writes: >>> Hi! >>> >>> This comes up in #gcc on IRC every so often, so finally >>> writing an RFC. >>> >> [...] >>> TL;DR: The proposal is: >

Re: [RFC] MAINTAINERS: require a BZ account field

Sam James via Gcc writes: > Hi! > > This comes up in #gcc on IRC every so often, so finally > writing an RFC. > > What? > --- > > I propose that MAINTAINERS be modified to be of the form, > adding an extra field for their GCC/sourceware account: >account> > Joe Bloggs

Re: [RFC] Merge strathegy for all-SLP vectorizer

Richard Biener via Gcc writes: > Hi, > > I'd like to discuss how to go forward with getting the vectorizer to > all-SLP for this stage1. While there is a personal branch with my > ongoing work (users/rguenth/vect-force-slp) branches haven't proved > themselves working well for collaboration. Spe

Re: Discussion about arm/aarch64 testcase failures seen with patch for PR111673

Richard Earnshaw writes: > On 28/11/2023 12:52, Surya Kumari Jangala wrote: >> Hi Richard, >> Thanks a lot for your response! >> >> Another failure reported by the Linaro CI is as follows : >> (Note: I am planning to send a separate mail for each failure, as this will >> make >> the discussion e

Re: Arm assembler crc issue

Iain Sandoe writes: > Hi Richard, > > > I am being bitten by a problem that falls out from the code that emits > > .arch Armv8.n-a+crc > > when the arch is less than Armv8-r. > The code that does this, in gcc/common/config/aarch64 is quite recent > (2022-09). Heh. A workaround for one as

Re: ipa-inline & what TARGET_CAN_INLINE_P can assume

Andrew Pinski writes: > On Mon, Sep 25, 2023 at 10:16 AM Richard Sandiford via Gcc > wrote: >> >> Hi, >> >> I have a couple of questions about what TARGET_CAN_INLINE_P is >> alllowed to assume when called from ipa-inline. (Callers from the >> front-e

ipa-inline & what TARGET_CAN_INLINE_P can assume

Hi, I have a couple of questions about what TARGET_CAN_INLINE_P is alllowed to assume when called from ipa-inline. (Callers from the front-end don't matter for the moment.) I'm working on an extension where a function F1 without attribute A can't be inlined into a function F2 with attribute A.

Re: Question on aarch64 prologue code.

Iain Sandoe writes: > Hi Folks, > > On the Darwin aarch64 port, we have a number of cleanup test fails (pretty > much corresponding to the [still open] > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39244). However, let’s assume > that bug could be a red herring.. > > the underlying reason is

Re: Question about dynamic choosing vectorization factor for RVV

"juzhe.zh...@rivai.ai" writes: > Thanks Richi. > > I am trying to figure out how to adjust finish_cost to lower the LMUL > > For example: > > void > foo (int32_t *__restrict a, int32_t *__restrict b, int n) > { > for (int i = 0; i < n; i++) > a[i] = a[i] + b[i]; > } > > preferred_simd_mode p

Re: Hundreds of gcc.dg/guality failures on both 14 and 13.1 branches

Martin Jambor writes: > Hi, > > On Sat, Jul 15 2023, FX Coudert via Gcc wrote: >> Hi, >> >> I am finding it very hard to reliably compare test results and regressions >> with the very large number of gcc.dg/guality test failures that are >> apparently the new norm on x86_64-linux: more than one

Re: Taking Over MIPS Maintenance

YunQiang Su writes: > Greetings all, > > I would like to self-nominate as the new GCC MIPS maintainer. Matthew Fortune > is listed in MAINTAINERS as the current maintainer of GCC's MIPS Port. > However, it has been years since he left MIPS Technologies and had since been > inactive. > > I curre

Re: Default initialization of poly-ints

Jeff Law via Gcc writes: > On 1/3/23 04:16, Florian Weimer via Gcc wrote: >> It seems that the default constructor of the non-POD poly-ints does >> nothing. Is this intentional? I expected zero initialization, to match >> regular ints. > I think it was intentional. Rich

Re: RFC: Make builtin types only valid for some target features

"Kewen.Lin" writes: > Hi, > > I'm working to find one solution for PR106736, which requires us to > make some built-in types only valid for some target features, and > emit error messages for the types when the condition isn't satisfied. > A straightforward idea is to guard the registry of built

Re: [RFC] database with API information

Ulrich Drepper via Gcc writes: > I talked to Jonathan the other day about adding all the C++ library APIs to > the name hint file now that the size of the table is not really a concern > anymore. > > Jonathan mentioned that he has to create and maintain a similar file for > the module support. It

Re: [PATCH 0/3] picolibc: Add picolibc linking help

Keith Packard via Gcc-patches writes: > Picolibc is a C library for embedded systems based on code from newlib > and avr libc. To connect some system-dependent picolibc functions > (like stdio) to an underlying platform, the platform may provide an OS > library. > > This OS library must follow the

Re: try_finally_expr in must_not_throw_expr

Philipp Rimmele via Gcc writes: > Hi, > > i'm developing a GCC-Plugin. And i don't understand why there is a > "try_finally_expr" in a must_not_throw-Area in my AST. It happens in the > destructors. > Here is my AST: > function_decl Exception::__dt_base > 1: must_not_throw_expr(->void_type{voi

Re: Help with an ABI peculiarity

Iain Sandoe writes: > Hi Richard, >> On 20 Jan 2022, at 22:32, Richard Sandiford >> wrot>> Iain Sandoe writes: >>>> On 10 Jan 2022, at 10:46, Richard Sandiford >>>> wrot>> An alternative might be to make promote_function_arg a “prop

Re: Help with an ABI peculiarity

Iain Sandoe writes: >> On 10 Jan 2022, at 10:46, Richard Sandiford >> wrot>> An alternative might be to make promote_function_arg a “proper” >> ABI hook, taking a cumulative_args_t and a function_arg_info. >> Perhaps the return case should become a separate hook at

Re: How to generate a call inst. sequence?

Andras Tantos writes: > All, > > I'm working on porting GCC to a processor architecture that doesn't have > a (HW) stack nor a call instruction. This means that for calls, I need > to generate the following instruction sequence: > >     // move stack-pointer: >     $sp <- $sp-4 >     // load

Re: Help with an ABI peculiarity

Iain Sandoe writes: > Hi Folks, > > In the aarch64 Darwin ABI we have an unusual (OK, several unusual) feature of > the calling convention. > > When an argument is passed *in a register* and it is integral and less than > SI it is promoted (with appropriate signedness) to SI. This applies when

Re: Mass rename of C++ .c files to .cc suffix?

Martin Jambor writes: > Hi, > > Would anyone be terribly against mass renaming all *.c files (that are > actually C++ files) within the gcc subdirectory to ones with .cc suffix? > > We already have 47 files with suffix .cc directly in the gcc > subdirectory and 160 if we also count those in (non-t

Re: Some libgcc headers are missing the runtime exception

David Edelsohn writes: > On Fri, Jul 9, 2021 at 12:53 PM Richard Sandiford via Gcc > wrote: >> >> Hi, >> >> It was pointed out to me off-list that config/aarch64/value-unwind.h >> is missing the runtime exception. It looks like a few other files >> are

Some libgcc headers are missing the runtime exception

Hi, It was pointed out to me off-list that config/aarch64/value-unwind.h is missing the runtime exception. It looks like a few other files are too; a fuller list is: libgcc/config/aarch64/value-unwind.h libgcc/config/frv/frv-abi.h libgcc/config/i386/value-unwind.h libgcc/config/pa/pa64-hpux-lib.

Re: [PATCH] Port GCC documentation to Sphinx

Eli Zaretskii writes: >> Hans-Peter Nilsson writes: >> > I've read the discussion downthread, but I seem to miss (a recap >> > of) the benefits of moving to Sphinx. Maybe other have too and >> > it'd be a good idea to repeat them? Otherwise, the impression >> > is not so good, as all I see is b

Re: [PATCH] Port GCC documentation to Sphinx

Hans-Peter Nilsson writes: > I've read the discussion downthread, but I seem to miss (a recap > of) the benefits of moving to Sphinx. Maybe other have too and > it'd be a good idea to repeat them? Otherwise, the impression > is not so good, as all I see is bits here and there getting lost > in t

Re: RFC: New mechanism for hard reg operands to inline asm

Paul Koning via Gcc writes: >> On Jun 4, 2021, at 2:02 PM, Andreas Krebbel via Gcc wrote: >> >> Hi, >> >> I wonder if we could replace the register asm construct for >> inline assemblies with something a bit nicer and more obvious. >> E.g. turning this (real world example from IBM Z kernel code

Re: [RFC] Implementing detection of saturation and rounding arithmetic

Tamar Christina writes: > Hi All, > > We are looking to implement saturation support in the compiler. The aim is to > recognize both Scalar and Vector variant of typical saturating expressions. > > As an example: > > 1. Saturating addition: >char sat (char a, char b) >{ > int tmp =

Re: Could vector type of poly_int and compile-time constants be enabled at the same time ?

JojoR via Gcc writes: > Hi, > > I have a little know about for 'Sizes and offsets as runtime > invariants’, > > and need to add vector types like V2SImode as compile-time constants > with enabled vector types of runtime invariants. > > Could I enable two vector types at sa

Re: GCC association with the FSF

[ Like many others who have posted to this thread, I've contributed to GCC at various times as a hobby and at other times as a paid employee. Here I'm speaking as a personal contributor, not on behalf of my current employer. ] I think it's misleading to talk about GCC “leaving” or “disassoc

Re: Current limitations of define_subst

Colin McEwan via Gcc writes: > Hi all, > > I was wondering if anyone understands the rationale behind the current > limitations on (define_subst), ie. working only on (define_insn) and > (define_expand). > > A lot of md cleanup, as well as extra patterns for combiner use, could be > enabled by sup

Re: C++11 code in the gcc 10 branch

FX writes: >> When are you going to apply your fix that Richard S. approved on the >> 21st? > > When I remember how to set up gcc’s git with write access, and remember how > the new ChangeLog entries work. The times where I was a regular contributor > were the CVS and SVN times. > > I also wante

What is the type of vector signed + vector unsigned?

Any thoughts on what f should return in the following testcase, given the usual GNU behaviour of treating signed >> as arithmetic shift right? typedef int vs4 __attribute__((vector_size(16))); typedef unsigned int vu4 __attribute__((vector_size(16))); int f (void) { vs4 x

Re: C++11 code in the gcc 10 branch

FX via Gcc writes: > I’m trying to bootstrap a GCC 10 compiler on macOS with clang, and I am > getting errors in stage 1, because there is C++11 code that is rejected by > clang (because the bootstrap involves compiling stage 1 with -std=gnu++98, > online on master (see top-level configure.ac).

Re: wide int knowledge/bug?

Jakub Jelinek via Gcc writes: > On Tue, Oct 27, 2020 at 01:18:03PM -0400, Andrew MacLeod via Gcc wrote: >> I was looking at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97596 >> >> and the ranger is constructing some 128 bit constants and calling >> wide_int_to_tree to turn them into trees. >> >

Re: modified_between_p does not check for volatile memory

Tucker Kern via Gcc writes: > TL;DR > > In GCC 9.3, I believe modified_between_p should return 1 if the memory > reference is volatile. My layman's understanding of volatile memory is that > it could change at any time, and thus could be modified between any two > instructions. That's true, but i

Re: Can the "ATTRIBUTE_UNUSED" macro be removed if the paramter has being used in fact

"Hu, Jiangping" writes: > Hi, > > I find there are many "ATTRIBUTE_UNUSED" macros in the function parameter > lists, > but some of the parameters are used in the function bodies in fact. E.g. > > @@gcc/final.c > void > output_operand (rtx x, int code ATTRIBUTE_UNUSED) > { > if (x &&

Re: duplicate arm test results?

Christophe Lyon via Gcc writes: > On Wed, 23 Sep 2020 at 01:47, Martin Sebor wrote: >> >> On 9/22/20 9:15 AM, Christophe Lyon wrote: >> > On Tue, 22 Sep 2020 at 17:02, Martin Sebor wrote: >> >> >> >> Hi Christophe, >> >> >> >> While checking recent test results I noticed many posts with results

Re: A problem with one instruction multiple latencies and pipelines

Segher Boessenkool writes: >> Although this looks/sounds complicated, the advantage is that everything >> remains up-to-date. If we instead added a second attribute and only >> defined it for instructions like *add__, other instructions >> (including config/arm instructions) would still have type

Re: A problem with one instruction multiple latencies and pipelines

"Qian, Jianhua" writes: > Hi Richard and Segher > > I don't know if I exactly understood your discussion. > If I misunderstood, please let me know. > > I am trying to test these two cases. > Case 1. keep the TYPE attribute unchanged, add new attributes > It works well as below. > (define_a

Re: subreg vs vec_select

Ilya Leoshkevich writes: > On Fri, 2020-09-11 at 12:17 +0200, Ilya Leoshkevich wrote: >> On Fri, 2020-09-11 at 10:46 +0100, Richard Sandiford wrote: >> > Ilya Leoshkevich via Gcc writes: >> > > On Wed, 2020-09-09 at 16:09 -0500, Segher Boessenkool wrote: >>

Re: subreg vs vec_select

Ilya Leoshkevich via Gcc writes: > On Wed, 2020-09-09 at 16:09 -0500, Segher Boessenkool wrote: >> Hi Ilya, >> >> On Wed, Sep 09, 2020 at 11:50:56AM +0200, Ilya Leoshkevich via Gcc >> wrote: >> > I have a vector pseudo containing a single 128-bit value (V1TFmode) >> > and >> > I need to access it

Re: A problem with one instruction multiple latencies and pipelines

Segher Boessenkool writes: > On Thu, Sep 10, 2020 at 11:04:26AM +0100, Richard Sandiford wrote: >> Segher Boessenkool writes: >> > You can also use some other attributes to classify instructions, you >> > don't have to put it all in one "type" attribu

Re: A problem with one instruction multiple latencies and pipelines

Segher Boessenkool writes: > Hi! > > On Mon, Sep 07, 2020 at 09:20:59PM +0100, Richard Sandiford wrote: >> This is just personal opinion, but in general (from the point of view >> of a new port, or a new subport like SVE), I think the best approach >> to handling the &

Re: JUMP_LABEL returns NULL for the just created jump instruction

Anton Youdkevitch writes: > Folks, > > I'm trying to deal with CFG construction at RTL level and I bumped into a > problem > when I created a jump to a certain label. After the jump is created I try > to extract the > label using JUMP_LABEL but I get nothing. > > The code looks like like this: > >

Re: A problem with one instruction multiple latencies and pipelines

"Qian, Jianhua" writes: > Hi > > I'm adding a new machine model. I have a problem when writing the > "define_insn_reservation" for instruction scheduling. > How to write the "define_insn_reservation" for one instruction that there are > different latencies and pipelines according to parameter. >

Re: #line directives in generated C files

Pip Cet via Gcc writes: > I may be missing an obvious workaround, but it seems we currently emit > a #line directive when including lines from machine description files > in C files, but never emit a second directive when switching back to > the generated C file. This makes stepping through the ba

Re: arm-related links in need of updates

oke.texi > > > http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/ECM0359818_armv8m_security_extensions_reqs_on_dev_tools_1_0.pdf Thanks for the heads-up. I've applied the GCC patch below to trunk and all active branches, and applied the web patch too. Richard >From 0

Does -fstack-protector really need to clear registers?

PR96191 [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191] was a bug raised against the aarch64 implementation of -fstack-protector. As it happens, the same bug affected arm, but AFAICT those are the only two affected targets. -fstack-protector works by: * creating a special canary slot in the

Re: Ellipsis in varadic macro definitions

Jonathan Wakely via Gcc writes: > On Mon, 3 Aug 2020 at 11:28, Florian Weimer wrote: >> >> * Jonathan Wakely via Gcc: >> >> > On Sun, 2 Aug 2020 at 15:49, Philip R Brenan via Gcc >> > wrote: >> >> >> >> Hi *GCC*: >> >> >> >> On page: >> >> >> >> https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros

Re: SLP and dr_vec_info

Richard Biener writes: > I'm facing the issue that we have vector type dependent information > stored in dr_vec_info (the misalignment at least) and that with > BB vectorization (at least) we want to be able to access a DR group with > two different vector types. > > I've run into this with > htt

Re: Automatically generated ChangeLog files - PHASE 1

Martin Liška writes: > Hi. > > Thanks to Jakub, we finally set up an experimental environment: > gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git > > The repository now contains a new pre-commit hook that validates > the git commit format ([1]) and provides a reasonable error message > when violate

Re: performance of exception handling

Thomas Neumann via Gcc writes: >> Not all GCC/G++ targets are GNU/Linux and use GLIBC. A duplicate >> implementation in GLIBC creates its own set of advantages and >> disadvantages. > > so what should I do now? Should I try to move the lookup into GLIBC? Or > handled it within libgcc, as I had or

Re: Can we please have the old mailing list back

Bernd Edlinger writes: > On 4/2/20 11:01 AM, Richard Sandiford wrote: >> Bernd Edlinger writes: >>> On 4/1/20 8:51 AM, Bernd Edlinger wrote: >>>> On 3/26/20 4:27 PM, Bernd Edlinger wrote: >>>>> On 3/26/20 4:16 PM, Christopher Faylor wrote: >>&

Re: Can we please have the old mailing list back

Bernd Edlinger writes: > On 4/1/20 8:51 AM, Bernd Edlinger wrote: >> On 3/26/20 4:27 PM, Bernd Edlinger wrote: >>> On 3/26/20 4:16 PM, Christopher Faylor wrote: marc.info is an independent site that is not associated with sourceware.org. We don't control it. If you have questions

Re: Masked vector deficiencies

Andrew Stubbs writes: > Hi all, > > Up until now the AMD GCN port has been using exclusively 64-lane vectors > with masking for smaller sizes. > > This works quite well, where it works, but there remain many test cases > (and no doubt some real code) that refuse to vectorize because the > numbe

Re: Git ChangeLog policy for GCC Testsuite inquiry

changelog format should be one acceptable way of writing good patch descriptions, but not the only acceptable way. Sometimes the traditional changelog is better than a plain English description (the SVE PCS work being one recent example from my POV). But for modern VCSes there's IMO

Re: Git ChangeLog policy for GCC Testsuite inquiry

"H.J. Lu" writes: > On Fri, Jan 24, 2020 at 2:39 PM Paul Smith wrote: >> >> On Fri, 2020-01-24 at 22:45 +0100, Jakub Jelinek wrote: >> > > > In my experience the output of git log is a total mess so cannot >> > > > replace ChangeLogs. But we can well decide to drop ChangeLog for >> > > > the tes

Re: Aliasing rules for unannotated SYMBOL_REFs

Thanks for the answer, and sorry for slow follow-up. Got distracted by other things... Jeff Law writes: > On Sat, 2020-01-25 at 09:31 +0000, Richard Sandiford wrote: >> TL;DR: if we have two bare SYMBOL_REFs X and Y, neither of which have an >> associated source-level decl and n

Aliasing rules for unannotated SYMBOL_REFs

TL;DR: if we have two bare SYMBOL_REFs X and Y, neither of which have an associated source-level decl and neither of which are in an anchor block: (Q1) can a valid byte access at X+C alias a valid byte access at Y+C? (Q2) can a valid byte access at X+C1 alias a valid byte access at Y+C2, C1

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

"Richard Earnshaw (lists)" writes: > On 21/01/2020 17:20, Jason Merrill wrote: >> On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote: >>> On 21/01/2020 15:39, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists) wrote: >> Some examples would be us

Re: Could I obtain the forms needed to make a contribution?

Eric Curtin writes: > I want to add a compiler warning, if it will get accepted. It's a > -Wlines warning. My employer bans the __LINE__ macro as well as the > ones warned by the -Wdate-time warning, because there is a consensus > that the addition of whitespace or comments should not yield differ

Re: Code bloat due to silly IRA cost model?

Segher Boessenkool writes: >> My point was the extra pseudo<-pseudo2 move is created by combine for >> its own internal purposes > > And my point is that it is *not* internal purposes :-) This is done > because we no longer combine with the hard register, but combining with > just a register move

Re: Code bloat due to silly IRA cost model?

Georg-Johann Lay writes: > Am 11.12.19 um 18:55 schrieb Richard Sandiford: >> Georg-Johann Lay writes: >>> Hi, doesn't actually anybody know know to make memory more expensive >>> than registers when it comes to allocating registers? >>> >>> Wh

Re: Code bloat due to silly IRA cost model?

Segher Boessenkool writes: > On Fri, Dec 13, 2019 at 04:22:11PM +0000, Richard Sandiford wrote: >> Segher Boessenkool writes: >> > On Fri, Dec 13, 2019 at 12:45:47PM +, Richard Sandiford wrote: >> >> combine's to blame for the fact that we have two pse

Re: Code bloat due to silly IRA cost model?

Segher Boessenkool writes: > On Fri, Dec 13, 2019 at 12:45:47PM +0000, Richard Sandiford wrote: >> combine's to blame for the fact that we have two pseudo registers rather >> than one. See the comments about the avr-elf results in: >> >>https://gcc.gnu.org

Re: Code bloat due to silly IRA cost model?

Georg-Johann Lay writes: > Am 11.12.19 um 18:55 schrieb Richard Sandiford: >> Georg-Johann Lay writes: >>> Hi, doesn't actually anybody know know to make memory more expensive >>> than registers when it comes to allocating registers? >>> >>> Wh

Re: Code bloat due to silly IRA cost model?

Georg-Johann Lay writes: > Hi, doesn't actually anybody know know to make memory more expensive > than registers when it comes to allocating registers? > > Whatever I am trying for TARGET_MEMORY_MOVE_COST and > TARGET_REGISTER_MOVE_COST, ira-costs.c always makes registers more > expensive than

Re: Commit messages and the move to git

"Richard Earnshaw (lists)" writes: > The real question at this point is whether or not these commit summaries > are better than the existing ones. Personally, I think they are (or I > wouldn't have spent the time working on this), but I'm not the only > person with an interest here... +1 for hav

Re: Update on SVE/sizeless types for C and C++

Jim Wilson writes: > On Tue, Nov 12, 2019 at 2:12 PM Richard Sandiford > wrote: >> Are both RVV intrinsic proposals like SVE in that all sizeless types >> can be/are built into the compiler? If so, do you think the target hook >> added in: >> https://gcc.

Re: Update on SVE/sizeless types for C and C++

Hi Jim, Jim Wilson writes: > On Tue, Nov 12, 2019 at 8:06 AM Richard Sandiford > wrote: >> If the use of sizeless types does expand beyond SVE built-in types >> in future, the places that call the hook are the places that would >> need to deal directly with sizeless typ

Update on SVE/sizeless types for C and C++

Last year I posted a series of patches that added the concept of "sizeless" types to the C and C++ frontends, in order to support the SVE vector and predicate types: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00868.html That thread generated a lot of useful discussion and feedback, thanks. T

Re: Moving to C++11

Tom Tromey writes: >> "Jason" == Jason Merrill writes: > > Jason> Note that std::move is from C++11. > >>> I'm not too worried about requiring even a C++14 compiler, for the >>> set of products we still release latest compilers we have newer >>> GCCs available we can use for building them (ev

Re: Kyrylo Tkachov and Richard Sandiford appointed AArch64 maintainers.

Kyrill Tkachov writes: > On 9/26/19 8:02 AM, Ramana Radhakrishnan wrote: >> Hi, >> >> I'm pleased to announce that the GCC steering committee has appointed >> Kyrylo Tkachov and Richard Sandiford as AArch64 maintainers. >> >> Please join me in congra

Re: RTL alternative selection question

Andrew Stubbs writes: > On 23/09/2019 15:15, Segher Boessenkool wrote: >> On Mon, Sep 23, 2019 at 11:56:27AM +0100, Andrew Stubbs wrote: >>>[(set (match_operand:DI 0 "register_operand" "=Sg,v") >>> (ashift:DI >>>(match_operand:DI 1 "gcn_alu_operand" " Sg,v") >>>

Re: [testsuite] Effective-target depending on current compiler flags?

Christophe Lyon writes: > Hi, > > While looking at GCC validation results when configured for ARM > cortex-m33 by default, I noticed that > FAIL: gcc.target/arm/cmse/mainline/soft/cmse-5.c -march=armv8-m.main > -mthumb -mfloat-abi=soft -O0 scan-assembler msr\tAPSR_nzcvqg, lr > > The correspond

Re: Expansion of narrowing math built-ins into power instructions

Martin Jambor writes: > Hello, > > On Thu, Aug 22 2019, Segher Boessenkool wrote: >>> > Hi Tejas, >>> > >>> > [ Please do not top-post. ] >> >> On Thu, Aug 22, 2019 at 01:27:06PM +0530, Tejas Joshi wrote: >>> > What happens then? "It does not work" is very very vague. At least it >>> > seems the

Re: Expansion of narrowing math built-ins into power instructions

Richard Sandiford writes: >> And yes, it is icky. But it is sound, as far as I can see. > > I really disagree that it's sound, but no point me saying why again :-) > > (It could certainly be made to work with sufficient hacks of course, > like pretty much anything could

Re: Expansion of narrowing math built-ins into power instructions

Segher Boessenkool writes: > On Tue, Aug 20, 2019 at 01:59:06PM +0100, Richard Sandiford wrote: >> Segher Boessenkool writes: >> >> [(set (match_operand:SI 0 "register_operand" "=d") >> >> (truncate:SI >> >> (ls

Re: Expansion of narrowing math built-ins into power instructions

Segher Boessenkool writes: >> > And yes, various parts of GCC can manipulate RTL, doing substitution and >> > algebraic simplication and whatnot. All within the rules of RTL. And >> > that means nothing ever can "pass" a float_narrow, because there are no >> > rules that allow it to. >> >> You

Re: Expansion of narrowing math built-ins into power instructions

Tejas: given the controversy, I agree unspecs sound like a good approach for now. We can always go back and add the rtx codes later once there's agreement on what they should look like. Segher Boessenkool writes: > On Sat, Aug 17, 2019 at 09:21:00AM +0100, Richard Sandiford wrote:

Re: Expansion of narrowing math built-ins into power instructions

There we use US_PLUS and SS_PLUS rtx codes for unsigned and signed saturating plus respectively, rather than: (unsigned_sat '(plus a b)) (signed_sat '(plus a b)) Using dedicated codes might seem clunky. But it's simple, safe, and fits the existing model without special cases

Re: Expansion of narrowing math built-ins into power instructions

Segher Boessenkool writes: > On Thu, Aug 15, 2019 at 01:47:47PM +0100, Richard Sandiford wrote: >> Tejas Joshi writes: >> > Hello. >> > I just wanted to make sure that I am looking at the correct code here. >> > Except for rtl.def where I should be introducin

Re: Expansion of narrowing math built-ins into power instructions

Tejas Joshi writes: > Hello. > I just wanted to make sure that I am looking at the correct code here. > Except for rtl.def where I should be introducing something like > float_contract (or float_narrow?) and also simplify-rtx.c, breakpoints > set on functions around expr.c, cfgexpand.c where I gre

Re: Use predicates for RTL objects

Segher Boessenkool writes: > On Wed, Aug 07, 2019 at 01:39:53PM -0400, Arvind Sankar wrote: >> On Wed, Aug 07, 2019 at 12:33:53PM -0500, Segher Boessenkool wrote: >> > On Wed, Aug 07, 2019 at 12:15:29PM -0400, Arvind Sankar wrote: >> > > I would also like to get some comments on the following idea

Re: [RFC] Disabling ICF for interrupt functions

[Catching up after being away, sorry if this has already been resolved.] Jozef Lawrynowicz writes: > For MSP430, the folding of identical functions marked with the "interrupt" > attribute by -fipa-icf-functions results in wrong code being generated. > Interrupts have different calling conventions

Re: Renaming vec_step in tree-vect-loop.c (to fix build on powerpc/clang)

Gerald Pfeifer writes: > I have seen an increasing number of reports of GCC failing to > build with clang on powerpc (on FreeBSD, though that's probably > immaterial). > > Turns out that clang has vec_step as a reserved word on powerpc > with AltiVec. > > We OTOH use vec_step s as a variable name

Re: [GSoC-19] Implementing narrowing functions like fadd

Tejas Joshi writes: > Hello. > I have added fadd variants in builtins.def. For fadd and faddl > variants, I had to introduce builtin function types in > builtin-types.def : > > +DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_DOUBLE_DOUBLE, > +BT_FLOAT, BT_DOUBLE, BT_DOUBLE) > +DEF_FUNCTION_T

Re: Possibly latent issue with combine ?

Segher Boessenkool writes: > On Wed, Jun 26, 2019 at 07:27:20PM +0530, Prathamesh Kulkarni wrote: >> combine then does following combinations: >> >> Trying 7 -> 9: >> 7: r90:V2DI=r89:V2DI>r93:V2DI >> REG_DEAD r93:V2DI >> REG_DEAD r89:V2DI >> 9: r91:V2DF=r90:V2DI#0 >> REG

  1   2   3   4   5   6   >