RE: [PATCH] Add a bit dislike for separate mem alternative when op is REG_P.

> > In the PR, the spill happens in the initial basic block of the function, > > i.e. > > the one with the highest frequency. > > > > Also as noted in the PR, swapping the 'unlikely' branch to 'likely' avoids > > the spill, > > even though it does not affect the frequency of the initial basic bl

[PATCH] testsuite: constraint some of fp tests to hard_float

These tests validate fp conversions with various rounding modes which would not work on soft-float ABIs. On -march=rv64imac/-mabi=lp64 this reduces 5 unique failures (overall 35 due to multi flag combination builds) gcc/testsuite/Changelog: * gcc.dg/torture/fp-double-convert-float-1.c: Ad

Re: [PATCH v3] RISC-V/testsuite: constraint some of tests to hard_float

Committed, thanks! On Fri, May 27, 2022 at 10:37 AM Vineet Gupta wrote: > > Commit 9ddd44b58649d1d ("RISC-V: Provide `fmin'/`fmax' RTL pattern") added > tests which check for hard float instructions which obviously fails on > soft-float ABI builds. > > And my recent commit b646d7d279ae ("RISC-V:

Re: [PATCH] Add a bit dislike for separate mem alternative when op is REG_P.

On Fri, May 27, 2022 at 5:12 AM Vladimir Makarov via Gcc-patches wrote: > > > On 2022-05-24 23:39, liuhongt wrote: > > Rigt now, mem_cost for separate mem alternative is 1 * frequency which > > is pretty small and caused the unnecessary SSE spill in the PR, I've tried > > to rework backend cost mo

RE: [PATCH] Add a bit dislike for separate mem alternative when op is REG_P.

> -Original Message- > From: Alexander Monakov > Sent: Friday, May 27, 2022 5:39 PM > To: Liu, Hongtao > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] Add a bit dislike for separate mem alternative when op is > REG_P. > > On Wed, 25 May 2022, liuhongt via Gcc-patches wrote: > >

Re: [PATCH] c++: don't substitute TEMPLATE_PARM_CONSTRAINT [PR100374]

On 5/29/22 22:10, Jason Merrill wrote: On 5/27/22 14:05, Patrick Palka wrote: This makes us avoid substituting into the TEMPLATE_PARM_CONSTRAINT of each template parameter except as necessary for (friend) declaration matching, like we already do for the overall TEMPLATE_PARMS_CONSTRAINTS of a te

Re: [PATCH] c++: don't substitute TEMPLATE_PARM_CONSTRAINT [PR100374]

On 5/27/22 14:05, Patrick Palka wrote: This makes us avoid substituting into the TEMPLATE_PARM_CONSTRAINT of each template parameter except as necessary for (friend) declaration matching, like we already do for the overall TEMPLATE_PARMS_CONSTRAINTS of a template parameter list. Bootstrapped and

Re: [PATCH] c++: Add !TYPE_P assert to type_dependent_expression_p [PR99080]

On 5/27/22 12:43, Marek Polacek wrote: On Fri, May 27, 2022 at 11:52:12AM -0400, Jason Merrill wrote: On 5/26/22 20:33, Marek Polacek wrote: As discussed here: , type_dependent_expression_p should not be called with a type arg

Ping [PATCH v2, rs6000] Fix ICE on expand bcd__ [PR100736]

Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595661.html Thanks. On 26/5/2022 下午 3:35, HAO CHEN GUI wrote: > Hi, > This patch fixes the ICE reported in PR100736. It removes the condition > check of finite math only flag not setting in "*_cc" pattern. > With or with

Ping [PATCH v3, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]

Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595164.html Thanks. On 18/5/2022 下午 4:52, HAO CHEN GUI wrote: > Hi, > This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000. > Tests show that outputs of xs[min/max]dp are consistent with the standard >

Re: [PATCH v3] DSE: Use the constant store source if possible

On 5/29/2022 3:43 PM, H.J. Lu wrote: On Sat, May 28, 2022 at 11:37 AM Jeff Law via Gcc-patches wrote: On 5/26/2022 2:43 PM, H.J. Lu via Gcc-patches wrote: On Thu, May 26, 2022 at 04:14:17PM +0100, Richard Sandiford wrote: "H.J. Lu" writes: On Wed, May 25, 2022 at 12:30 AM Richard Sandi

[PATCH v2] RISC-V: bitmanip: improve constant-loading for (1ULL << 31) in DImode

The SINGLE_BIT_MASK_OPERAND() is overly restrictive, triggering for bits above 31 only (to side-step any issues with the negative SImode value 0x8000/(-1ull << 31)/(1 << 31)). This moves the special handling of this SImode value (i.e. the check for (-1ull << 31) to riscv.cc and relaxes the SIN

Re: [PATCH v3] DSE: Use the constant store source if possible

On Sat, May 28, 2022 at 11:37 AM Jeff Law via Gcc-patches wrote: > > > > On 5/26/2022 2:43 PM, H.J. Lu via Gcc-patches wrote: > > On Thu, May 26, 2022 at 04:14:17PM +0100, Richard Sandiford wrote: > >> "H.J. Lu" writes: > >>> On Wed, May 25, 2022 at 12:30 AM Richard Sandiford > >>> wrote: >

nvptx: forward '-v' command-line option to assembler, linker (was: [MentorEmbedded/nvptx-tools] Issue 30: Ignore not-supported sm_* error without --verify (PR #31))

Hi! One item from : On 2022-04-11T04:25:01-0700, Tobias Burnus wrote: > we could consider invoking nvptx-as with `-v` from GCC to make this more > prominent – at least when building GCC itself. _(The user could do `

Re: [PATCH] c++: use current_template_constraints more

On 5/27/22 14:05, Patrick Palka wrote: gcc/cp/ChangeLog: * decl.cc (grokvardecl): Use current_template_constraints. (xref_tag): Likewise. * semantics.cc (finish_template_template_parm): Likewise. OK. --- gcc/cp/decl.cc | 13 +++-- gcc/cp/semantics.cc |

Re: [PATCH] c++: document comp_template_args's default args

On 5/27/22 14:07, Patrick Palka wrote: In passing, use bool for its return type. OK. gcc/cp/ChangeLog: * cp-tree.h (comp_template_args): Change return type to bool. * pt.cc (comp_template_args): Document default arguments. Change return type to bool and adjust returns

Re: [PATCH] libcpp: Ignore CPP_PADDING tokens in _cpp_parse_expr [PR105732]

On 5/27/22 04:16, Jakub Jelinek wrote: Hi! The first part of the following testcase (m1-m3 macros and its use) regressed with my PR89971 fix, but as the m1,m4-m5 and its use part shows, the problem isn't new, we can emit a CPP_PADDING token to avoid it from being adjacent to whatever comes after

[pushed] Darwin: Fix empty g++ command lines [PR105599].

An empty g++ command line should produce a diagnostic that there are no inputs. The PR is that currently Darwin produces a dignostic about missing link items instead - this is because (errnoeously), for this driver, we are creating a link job for empty command lines. The problem occurs in four st

[PATCH v5] tree-optimization/101186 - extend FRE with "equivalence map" for condition prediction

Hi, attached is a new version of the patch. The changes are: - Skip using temporary equivalences for floating-point values, because folding expressions can generate incorrect values. For example, operations on 0.0 and -0.0 may have different results. - Avoid inserting duplicated back-refs from val

[PATCH 4/4] xtensa: Add clrsbsi2 insn pattern

> (clrsb:m x) > Represents the number of redundant leading sign bits in x, represented > as an integer of mode m, starting at the most significant bit position. This explanation is just what the NSA instruction (not ever emitted before) calculates in Xtensa ISA. gcc/ChangeLog: * config/

[PATCH 2/4] xtensa: Make one_cmplsi2 optimizer-friendly

In Xtensa ISA, there is no single machine instruction that calculates unary bitwise negation. But a few optimizers assume that bitwise negation can be done by a single insn. As a result, '((x < 0) ? ~x : x)' cannot be optimized to '(x ^ (x >> 31))' ever before, for example. This patch relaxes s

[PATCH 3/4] xtensa: Optimize '(~x & y)' to '((x & y) ^ y)'

In Xtensa ISA, there is no single machine instruction that calculates unary bitwise negation. gcc/ChangeLog: * config/xtensa/xtensa.md (*andsi3_bitcmpl): New insn_and_split pattern. gcc/testsuite/ChangeLog: * gcc.target/xtensa/check_zero_byte.c: New. --- gcc/config/xte

[PATCH 1/4] xtensa: Implement bswaphi2 insn pattern

This patch adds bswaphi2 insn pattern that is one instruction less than the default expansion. gcc/ChangeLog: * config/xtensa/xtensa.md (bswaphi2): New insn pattern. --- gcc/config/xtensa/xtensa.md | 10 ++ 1 file changed, 10 insertions(+) diff --git a/gcc/config/xtensa/xtensa.