Re: [PATCH] ipa: Check cst type when propagating controled uses info (PR 105639)

On Thu, May 26, 2022 at 4:47 PM Martin Jambor wrote: > > Hi, > > PR 105639 shows that code with type-mismatches can trigger an assert > after runnning into a branch that was inteded only for references to > variables - as opposed to references to functions. Fixed by moving > the condition from th

[PATCH v3 9/9] RISC-V: Introduce predicate "riscv_sync_memory_operand" [PR 100266]

Atomic instructions require zero-offset memory addresses. If we allow all addresses, the nonzero-offset addresses will be prepared in an extra register in an extra instruction before the actual atomic instruction. This patch introduces the predicate "riscv_sync_memory_operand", which restricts the

[PATCH v3 8/9] RISC-V: Add s.ext-consuming INSNs for LR and SC [PR 100266]

The current model of the LR and SC INSNs requires a sign-extension to use the generated SImode value for conditional branches, which only operate on XLEN registers. However, the sign-extension is actually not required in both cases, therefore this patch introduces additional INSNs that consume the

[PATCH v3 7/9] RISC-V: Model INSNs for LR and SC [PR 100266]

In order to emit LR/SC sequences, let's provide INSNs, which take care of memory ordering constraints. gcc/ PR 100266 * config/rsicv/sync.md (UNSPEC_LOAD_RESERVED): New. * config/rsicv/sync.md (UNSPEC_STORE_CONDITIONAL): New. * config/riscv/sync.md (riscv_load_r

[PATCH v3 6/9] RISC-V: Implement atomic_{load,store} [PR 100265]

A recent commit introduced a mechanism to emit proper fences for RISC-V. Additionally, we already have emit_move_insn (). Let's reuse this code and provide atomic_load and atomic_store for RISC-V (as defined in section "Code Porting and Mapping Guidelines" of the unpriv spec). Note, that this works

[PATCH v3 5/9] RISC-V: Emit fences according to chosen memory model [PR 100265]

mem_thread_fence gets the desired memory model as operand. Let's emit fences according to this value (as defined in section "Code Porting and Mapping Guidelines" of the unpriv spec). gcc/ PR 100265 * config/riscv/sync.md (mem_thread_fence): Emit fences according t

[PATCH v3 4/9] RISC-V: Use STORE instead of AMOSWAP for atomic stores [PR 100265]

Using AMOSWAP as atomic store does not allow us to do sub-word accesses. Further, it is not consistent with our atomic_load () implementation. The benefit of AMOSWAP is that the resulting code sequence will be smaller (comapred to FENCE+STORE), however, this does not weight out for the lack of sub-

[PATCH v3 3/9] RISC-V: Eliminate %F specifier from riscv_print_operand() [PR 100265]

A previous patch took care, that the proper memory ordering suffixes for AMOs are emitted. Therefore there is no reason to keep the fence generation mechanism for release operations. gcc/ PR 100265 * config/riscv/riscv.c (riscv_memmodel_needs_release_fence): Remove fu

[PATCH v3 2/9] RISC-V: Emit proper memory ordering suffixes for AMOs [PR 100265]

The ratified A extension supports '.aq', '.rl' and '.aqrl' as memory ordering suffixes. Let's emit them in case we get a '%A' conversion specifier for riscv_print_operand(). As '%A' was already used for a similar, but restricted, purpose (only '.aq' was emitted so far), this does not require any o

[PATCH v3 1/9] RISC-V: Simplify memory model code [PR 100265]

We don't have any special treatment of MEMMODEL_SYNC_* values, so let's hide them behind the memmodel_base() function. gcc/ PR 100265 * config/riscv/riscv.c (riscv_memmodel_needs_amo_acquire): Ignore MEMMODEL_SYNC_* values. * config/riscv/riscv.c (riscv_memmod

[PATCH v3 0/9] [RISC-V] Atomics improvements

This series provides a cleanup of the current atomics implementation of RISC-V (PR100265: Use proper fences for atomic load/store). The first patch could be squashed into the following patches, but I found it easier to understand the chances with it in place. The series has been tested as follows

[COMMITTED] xtensa: Improve bswap[sd]i2 insn patterns

From: Takayuki 'January June' Suwa This patch makes bswap[sd]i2 better register allocation, and reconstructs bswapsi2 in order to take advantage of GIMPLE manual byte-swapping recognition. gcc/ChangeLog: * config/xtensa/xtensa.md (bswapsi2): New expansion pattern. (bswapsi2_inte

Re: [PATCH v3 4/5] xtensa: Add setmemsi insn pattern

On Mon, May 23, 2022 at 8:52 AM Takayuki 'January June' Suwa wrote: > > This patch introduces setmemsi insn pattern of two kinds, unrolled loop and > small loop, for fixed small length and constant initialization value. > > gcc/ChangeLog: > > * gcc/config/xtensa/xtensa-protos.h > (

Re: [PATCH v3 4/5] xtensa: Add setmemsi insn pattern

On Thu, May 26, 2022 at 8:00 PM Takayuki 'January June' Suwa wrote: > > On 2022/05/27 1:57, Max Filippov wrote: > > is that something that can be addressed in this patch? > > seems hard to resolve, because the RTL-generation pass passes only 68 > bytes in that case: ... > this behavior does not oc

Re: [PATCH v3 4/5] xtensa: Add setmemsi insn pattern

On 2022/05/27 1:57, Max Filippov wrote: is that something that can be addressed in this patch? seems hard to resolve, because the RTL-generation pass passes only 68 bytes in that case: void f(char *p); void g(void) { char c[72] = {0}; f(c); } without this patch, we would ge

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

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: Inhibit FP <--> int register moves via tune param") is guilty of same crime. So cons

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

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. So constraint with "dg-require-effective-target hard_float" This reduces bunch of new RV failures on trunk since that commit. |

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

From: Vineet Gupta 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. So constraint with "dg-require-effective-target hard_float" This reduces bunch of new RV failures on trunk

[PATCH] c-family: fix attribute constructor ICE [PR90658]

Here the C compiler crashes because a FUNCTION_DECL got into get_priority -> default_conversion, and the C FE's version of d_c specifically asserts that it doesn't get a FUNCTION_DECL. All uses of default_conversion in c-attribs.cc are guarded by != IDENTIFIER_NODE && != FUNCTION_DECL, but get_pri

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

As discussed here: , type_dependent_expression_p should not be called with a type argument. I promised I'd add an assert so here it is. One place needed adjusting, the comment explains why. Bootstrapped/regtested on x86_64-pc-l

[PATCH] libgompd: Add ompd_get/rel_display_control_vars

libgomp/ChangeLog 2022-05-27 Mohamed Atef * libgompd.map (ompd_get_display_control_vars, ompd_rel_display_control_vars): New global symbol versions. * env.c: (gompd_buffer, gompd_env_buff_size): New Variables. (dump_icvs): New function. (initialize_env): call dump_icvs. * ompd-icv.c: (ompd_get

Re: [PATCH] c++: cv-quals of dummy obj for non-dep memfn call [PR105637]

On Thu, 26 May 2022, Jason Merrill wrote: > On 5/26/22 14:57, Patrick Palka wrote: > > On Thu, 26 May 2022, Patrick Palka wrote: > > > > > Here we expect the calls to BaseClass::baseDevice resolve to the second, > > > third and fourth overloads respectively in light of the cv-qualifiers > > > of

[committed] libstdc++: Fix narrowing conversions for 16-bit size_t [PR105681]

Tested x86_64-linux, bootstrapped msp430-elf, pushed to trunk. -- >8 -- On a 16-bit target such as msp430 we get errors about narrowing long values to size_t, which is only 16-bit. When --enable-libstdcxx-pch is used the header breaks the build because of these narrowing errors. libstdc++-v3/Ch

[committed] libstdc++: Fix atomic and error_code printers for versioned namespace

Tested x86_64-linux, pushed to trunk. -- >8 -- This fixes the printers to work with std::__8::atomic and std::__v8::ios_errc and std::__v8::future_errc. libstdc++-v3/ChangeLog: * python/libstdcxx/v6/printers.py (StdErrorCodePrinter): Make lookup for ios_errc and future_errc chec

[committed] libstdc++: Move std::iostream_category() definition to new file

Tested x86_64-linux, pushed to trunk. -- >8 -- This fixes a missing symbol when the dual ABI is disabled, e.g. for the versioned namespace build. libstdc++-v3/ChangeLog: * src/c++11/Makefile.am: Add new source file. * src/c++11/Makefile.in: Regenerate. * src/c++11/cxx11-

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

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 model, but RA still not happy with that(regress somewhere else). I think the root cause o

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

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: > >> > >> "H.J. Lu via Gcc-patches" writes: > >> > On Mon, May 23, 2022 at 12:38:06PM +0200, Richard Biener wrote: > >> >> On Sat, May 21, 2022

Re: [PATCH] c++: cv-quals of dummy obj for non-dep memfn call [PR105637]

On 5/26/22 14:57, Patrick Palka wrote: On Thu, 26 May 2022, Patrick Palka wrote: Here we expect the calls to BaseClass::baseDevice resolve to the second, third and fourth overloads respectively in light of the cv-qualifiers of 'this' in each case. But ever since r12-6075-g2decd2cabe5a4f, the c

Re: [PATCH v2] c++: suppress -Waddress warnings with *_cast [PR105569]

On 5/26/22 09:33, Marek Polacek wrote: On Thu, May 26, 2022 at 09:26:16AM -0400, Jason Merrill wrote: On 5/25/22 16:25, Marek Polacek wrote: On Wed, May 18, 2022 at 09:43:47AM -0400, Jason Merrill wrote: On 5/16/22 13:06, Marek Polacek wrote: dynamic_cast can legally return nullptr, so I don'

Re: [PATCH, rs6000] Clean up the option_mask defines (part 1)

On Thu, 2022-05-26 at 13:31 -0500, Segher Boessenkool wrote: > > > > On Thu, May 26, 2022 at 09:40:18AM -0500, will schmidt wrote: > > On Thu, 2022-05-26 at 05:47 -0500, Segher Boessenkool wrote: > > > I'll dig a bit more, but would handle that in a separate > > patch. > > Can you please make

Re: [x86 PATCH] Pre-reload splitter to transform and; cmp into not; test.

On Thu, May 26, 2022 at 8:41 PM Roger Sayle wrote: > > > A common idiom for testing if a specific set of bits is set in a value > is to use "(X & Y) == Y", which on x86 results in an AND followed by a > CMP. A slightly improved implementation is to instead use (~X & Y)==0, > that uses a NOT and a

Re: [PATCH] c++: cv-quals of dummy obj for non-dep memfn call [PR105637]

On Thu, 26 May 2022, Patrick Palka wrote: > Here we expect the calls to BaseClass::baseDevice resolve to the second, > third and fourth overloads respectively in light of the cv-qualifiers > of 'this' in each case. But ever since r12-6075-g2decd2cabe5a4f, the > calls incorrectly resolve to the fi

[x86 PATCH] Pre-reload splitter to transform and;cmp into not;test.

A common idiom for testing if a specific set of bits is set in a value is to use "(X & Y) == Y", which on x86 results in an AND followed by a CMP. A slightly improved implementation is to instead use (~X & Y)==0, that uses a NOT and a TEST (or ANDN where available); still two "fast" instructions,

[PATCH] c++: cv-quals of dummy obj for non-dep memfn call [PR105637]

Here we expect the calls to BaseClass::baseDevice resolve to the second, third and fourth overloads respectively in light of the cv-qualifiers of 'this' in each case. But ever since r12-6075-g2decd2cabe5a4f, the calls incorrectly resolve to the first overload at instantiation time. This happens b

Re: [PATCH, rs6000] Clean up the option_mask defines (part 1)

On Thu, May 26, 2022 at 09:40:18AM -0500, will schmidt wrote: > On Thu, 2022-05-26 at 05:47 -0500, Segher Boessenkool wrote: > > Yeah, the longer names are a bit annoying in any case. We'll get > > used > > to it (if those long lines are fixed ;-) ) > > Agree. I would not be opposed to somewhat

Re: [PATCH v4, rs6000] Add V1TI into vector comparison expand [PR103316]

On Thu, May 26, 2022 at 09:16:59AM -0400, David Edelsohn wrote: > Does Power10 fully support int128 in 32 bit mode? I would expect no, > so the additional test is required. It isn't supported on any 32-bit ABI, Power or not. It would simplify many things if it was though! Segher

Re: [PATCH 5/5] xtensa: Improve bswap[sd]i2 insn patterns

On Fri, May 13, 2022 at 6:35 AM Takayuki 'January June' Suwa wrote: > > This patch makes bswap[sd]i2 better register allocation, and reconstructs > bswapsi2 in order to take advantage of GIMPLE manual byte-swapping > recognition. > > gcc/ChangeLog: > > * gcc/config/xtensa/xtensa.md (bswaps

Re: [PATCH v3 4/5] xtensa: Add setmemsi insn pattern

On Mon, May 23, 2022 at 8:52 AM Takayuki 'January June' Suwa wrote: > > This patch introduces setmemsi insn pattern of two kinds, unrolled loop and > small loop, for fixed small length and constant initialization value. > > gcc/ChangeLog: > > * gcc/config/xtensa/xtensa-protos.h > (

Re: [PATCH 3/5] xtensa: Fix instruction counting regarding block move expansion

On Fri, May 13, 2022 at 6:35 AM Takayuki 'January June' Suwa wrote: > > This patch makes counting the number of instructions of the remainder > (modulo 4) part more accurate. > > gcc/ChangeLog: > > * gcc/config/xtensa/xtensa.cc (xtensa_expand_block_move): > Make instruction countin

Re: [PATCH 2/5] xtensa: Make use of IN_RANGE macro where appropriate

On Fri, May 13, 2022 at 6:35 AM Takayuki 'January June' Suwa wrote: > > No functional changes. > > gcc/ChangeLog: > > * gcc/config/xtensa/constraints.md (M, O): Use the macro. > * gcc/config/xtensa/predicates.md (addsubx_operand, > extui_fldsz_operand, > sext_fldsz_operand

Re: [PATCH 1/5] xtensa: Simplify EXTUI instruction maskimm validations

On Fri, May 13, 2022 at 6:35 AM Takayuki 'January June' Suwa wrote: > > No functional changes. > > gcc/ChangeLog: > > * gcc/config/xtensa/predicates.md (extui_fldsz_operand): Simplify. > * gcc/config/xtensa/xtensa.cc (xtensa_mask_immediate, print_operand): > Ditto. > --- >

[committed] libstdc++: Add constexpr to std::counted_iterator post-increment (LWG 3643)

Tested powerpc64le-linux, pushed to trunk. This can be backported to 11 and 12 too. -- >8 -- libstdc++-v3/ChangeLog: * include/bits/stl_iterator.h (counted_iterator::operator++(int)): Add 'constexpr' as per LWG 3643. * testsuite/24_iterators/counted_iterator/lwg3643.cc:

Re: [PATCH] AArch64: Cleanup option processing code

Wilco Dijkstra writes: > Further cleanup option processing. Remove the duplication of global > variables for CPU and tune settings so that CPU option processing is > simplified even further. Move global variables that need save and > restore due to target option processing into aarch64.opt. This r

Re: [PATCH V4 2/3] RISC-V:Cache Management Operation instructions

Hi Simon: Good catch, those cache operations should take an address operand. On Thu, May 26, 2022 at 7:58 PM Simon Cook wrote: > > Hi, > > I've just tried using these builtins now these have landed in trunk, and > I have a question about the cbo builtins. > > Looking at the code being generate

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

"H.J. Lu" writes: > On Wed, May 25, 2022 at 12:30 AM Richard Sandiford > wrote: >> >> "H.J. Lu via Gcc-patches" writes: >> > On Mon, May 23, 2022 at 12:38:06PM +0200, Richard Biener wrote: >> >> On Sat, May 21, 2022 at 5:02 AM H.J. Lu via Gcc-patches >> >> wrote: >> >> > >> >> > When recording

[PATCH] c++: fix broken copy elision with nested TARGET_EXPRs [PR105550]

In this problem, we are failing to properly perform copy elision with a conditional operator, so this: constexpr A a = true ? A{} : A{}; fails with: error: 'A{((const A*)(&))}' is not a constant expression The whole initializer is TARGET_EXPR }> : TARGET_EXPR }>> where the outermost TAR

[PATCH] ipa: Check cst type when propagating controled uses info (PR 105639)

Hi, PR 105639 shows that code with type-mismatches can trigger an assert after runnning into a branch that was inteded only for references to variables - as opposed to references to functions. Fixed by moving the condition from the assert to the guarding if statement. Bootstrapped and tested on

Re: [PATCH, rs6000] Clean up the option_mask defines (part 1)

On Thu, 2022-05-26 at 05:47 -0500, Segher Boessenkool wrote: > Hi! > Hi, Thanks Kewen and Segher for the reviews. Additional comments below. > On Thu, May 26, 2022 at 03:01:37PM +0800, Kewen.Lin wrote: > > on 2022/5/26 14:12, Kewen.Lin via Gcc-patches wrote: > > > on 2022/5/26 04:25, will sch

[PATCH] Mips: Enable asynchronous unwind tables with both ASAN and LSAN

Enable asynchronous unwind tables with both ASAN and TSAN for correct back-trace. LLVM currently enables asynchronous unwind tables for: ASAN, HWSAN, TSAN, MSAN, and DFSAN. HWSAN is currently available only on AArch64, while MSAN and DFSAN are not available at all. Also, LLVM checks is '-ffreest

Re: [PATCH v2] c++: suppress -Waddress warnings with *_cast [PR105569]

On Thu, May 26, 2022 at 09:26:16AM -0400, Jason Merrill wrote: > On 5/25/22 16:25, Marek Polacek wrote: > > On Wed, May 18, 2022 at 09:43:47AM -0400, Jason Merrill wrote: > > > On 5/16/22 13:06, Marek Polacek wrote: > > > > dynamic_cast can legally return nullptr, so I don't think it's helpful > >

Re: [PATCH v2] c++: suppress -Waddress warnings with *_cast [PR105569]

On 5/25/22 16:25, Marek Polacek wrote: On Wed, May 18, 2022 at 09:43:47AM -0400, Jason Merrill wrote: On 5/16/22 13:06, Marek Polacek wrote: dynamic_cast can legally return nullptr, so I don't think it's helpful for -Waddress to warn for if (dynamic_cast(&ref)) // ... More generally

Re: [PATCH] c++: constrained partial spec forward decl [PR96363]

On 5/25/22 13:24, Patrick Palka wrote: Here during cp_parser_single_declaration for #2, we were calling associate_classtype_constraints for TPL (the primary template type) before maybe_process_partial_specialization could get a chance to notice that we're in fact declaring a distinct constrained

Re: [PATCH v4, rs6000] Add V1TI into vector comparison expand [PR103316]

On Thu, May 26, 2022 at 1:52 AM Kewen.Lin wrote: > > Hi Haochen, > > on 2022/5/26 13:30, HAO CHEN GUI wrote: > > Kewen, > > Thanks so much for your advice. Just one question about effective-target. > > > > For the test cases, it needs both power10_ok and int128 support. I saw > > some > > exi

[committed 3/3] libstdc++: Refactor includes for unordered containers

Tested powerpc64le-linux, pushed to trunk. -- >8 -- This moves some #include directives to the relevant place. For example, needs so should include it directly instead of relying on and to do so first. libstdc++-v3/ChangeLog: * include/bits/functional_hash.h (__is_fast_hash): Add do

[committed 1/3] libstdc++: Make headers include their prerequisites

From: Nathan Sidwell Tested powerpc64le-linux, pushed to trunk. -- >8 -- These headers were relying on their includers having already included some prerequisites. That makes them unsuitable to be header-units. So directly include the needed headers. Reviewed-by: Jonathan Wakely libstdc++-v

[committed 2/3] libstdc++: Remove some unnecessary includes

Tested powerpc64le-linux, pushed to trunk. -- >8 -- These headers do not use anything in directly, and it's included by and anyway, because they do need it. libstdc++-v3/ChangeLog: * include/bits/ranges_algobase.h: Do not include . * include/std/string: Likewise.

Re: [PATCH V4 2/3] RISC-V:Cache Management Operation instructions

Hi, I've just tried using these builtins now these have landed in trunk, and I have a question about the cbo builtins. Looking at the code being generated it looks like these builtins return an int and take no arguments, but reading the instructions these should instead take an int and retur

Re: [PATCH, rs6000] Clean up the option_mask defines (part 1)

Hi! On Thu, May 26, 2022 at 03:01:37PM +0800, Kewen.Lin wrote: > on 2022/5/26 14:12, Kewen.Lin via Gcc-patches wrote: > > on 2022/5/26 04:25, will schmidt via Gcc-patches wrote: > >> We have an assortment of MASK and OPTION_MASK #defines throughout > >> the rs6000 code, MASK_ALTIVEC and OPTION_MAS

Re: [PATCH][_GLIBCXX_INLINE_VERSION] Fix std::span pretty printer

On Thu, 26 May 2022 at 00:38, Jonathan Wakely wrote: > > On Thu, 26 May 2022 at 00:34, Jonathan Wakely wrote: > > > > On Wed, 25 May 2022 at 21:29, François Dumont via Libstdc++ > > wrote: > > > > > > Hi > > > > > > Here is a patch to fix std::span pretty printer in versioned > > > namespac

[committed 1/2] libstdc++: Remove redundancy in test pathnames

Tested x86_64-linux, pushed to trunk. -- >8 -- Repeating "explicit_instantiation" in these long pathnames is not necessary. libstdc++-v3/ChangeLog: * testsuite/20_util/duration/requirements/explicit_instantiation/explicit_instantiation.cc: Moved to... * testsuite/20_uti

[committed 2/2] libstdc++: Rename tests like .../wchar_t/1.cc to .../wchar_t.cc

Tested x86_64-linux, pushed to trunk. -- >8 -- There's no need to have directories containing a single test file, we can rename the files to the directory names and remove the directories. The dejagnu proc that filters out wchar_t tests just checks for "wchar_t" anywhere in the path, so will wor

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

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 without this flag, we still can use "cror" to check if either two bits of CC is set or not for "fp_two" codes. We don't need a reverse comparison (impl

Re: [ping2][PATCH 0/8][RFC] Support BTF decl_tag and type_tag annotations

On 5/24/22 10:04 AM, David Faust wrote: On 5/24/22 09:03, Yonghong Song wrote: On 5/24/22 8:53 AM, David Faust wrote: On 5/24/22 04:07, Jose E. Marchesi wrote: On 5/11/22 11:44 AM, David Faust wrote: On 5/10/22 22:05, Yonghong Song wrote: On 5/10/22 8:43 PM, Yonghong Song wrote

[PATCH 3/3][ARM] STAR-MC1 CPU Support - docs: Add star-mc1 core

Hi, This is the patch to add star-mc1 in the Arm -mtune and -mfix-cmse-cve-2021-35465 sections of gcc invoke.texi documentation. Is it OK for trunk? Regards, jasonwucjFrom b3bd24d842b6284f2b893caa658975d9d746be73 Mon Sep 17 00:00:00 2001 From: Chung-Ju Wu Date: Thu, 26 May 2022 05:15:13 +

[PATCH 2/3][ARM] STAR-MC1 CPU Support - arm: Add individual star-mc1 cost tables and cost functions

Hi, Attached is the patch to provide star-mc1 specific cost functions and tables. Given these individual implementation, developers are able to make their own adjustment to fine-tune star-mc1 performance without affecting other cpu configurations. Bootstrapped and tested on arm-none-eabi. Is it

[PATCH 1/3][ARM] STAR-MC1 CPU Support - arm: Add star-mc1 core

Hi, STAR-MC1 is an embedded processor with armv8m architecture. Majorly it is designed to meet the requirements of AIoT application performance, power consumption and security. Early this month, star-mc1 is supported by the latest releases of MDK and CMSIS. For the completeness of Arm ecosystem,

Re: [PATCH, rs6000] Clean up the option_mask defines (part 1)

on 2022/5/26 14:12, Kewen.Lin via Gcc-patches wrote: > Hi Will, > > on 2022/5/26 04:25, will schmidt via Gcc-patches wrote: >> [PATCH, rs6000] Clean up the option_mask defines >> >> Hi, >> >> We have an assortment of MASK and OPTION_MASK #defines throughout >> the rs6000 code, MASK_ALTIVEC an