[PATCH] Minor improvement to genpreds.cc

[Roger Sayle]

This simple patch implements Richard Biener's suggestion in comment #6
of PR tree-optimization/52171 (from February 2013) that the insn-preds
code generated by genpreds can avoid using strncmp when matching constant
strings of length one.

The effect of this patch is best explained by the diff of insn-preds.cc:
<   if (!strncmp (str + 1, "g", 1))
---
>   if (str[1] == 'g')
3104c3104
<   if (!strncmp (str + 1, "m", 1))
---
>   if (str[1] == 'm')
3106c3106
<   if (!strncmp (str + 1, "c", 1))
---
>   if (str[1] == 'c')
...

The equivalent optimization is performed by GCC (but perhaps not by the
host compiler), but generating simpler/smaller code may encourage further
optimizations (such as use of a switch statement).

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check with no new failures.  Ok for mainline?


2022-05-22  Roger Sayle  

gcc/ChangeLog
* genpreds.cc (write_lookup_constraint_1): Avoid generating a call
to strncmp for strings of length one.

Roger
--

diff --git a/gcc/genpreds.cc b/gcc/genpreds.cc
index f71da09..4571ac7 100644
--- a/gcc/genpreds.cc
+++ b/gcc/genpreds.cc
@@ -1089,10 +1089,15 @@ write_lookup_constraint_1 (void)
{
  do
{
- printf ("  if (!strncmp (str + 1, \"%s\", %lu))\n"
- "return CONSTRAINT_%s;\n",
- c->name + 1, (unsigned long int) c->namelen - 1,
- c->c_name);
+ if (c->namelen > 2)
+   printf ("  if (!strncmp (str + 1, \"%s\", %lu))\n"
+   "return CONSTRAINT_%s;\n",
+   c->name + 1, (unsigned long int) c->namelen - 1,
+   c->c_name);
+ else
+   printf ("  if (str[1] == '%c')\n"
+   "return CONSTRAINT_%s;\n",
+   c->name[1], c->c_name);
  c = c->next_this_letter;
}
  while (c);

[PATCH v2 0/1] RISC-V: Fix canonical extension order (K and J)

[Tsukasa OI via Gcc-patches]

PATCH v1:


Changes between v1 and v2:
-   Added Signed-off-by line (I didn't notice that this is required)
-   Applied the same change to Python script:
gcc/config/riscv/arch-canonicalize

Note that this kind of change is already made in GNU Binutils and LLVM.
GNU Binutils: commit c4dd8eb523fae5c9d312f4b7b21377eec66e70c3
LLVM: commit 7fe0630fcb6d52cb63463669c47f4846f7d9ccbf




Tsukasa OI (1):
  RISC-V: Fix canonical extension order (K and J)

 gcc/common/config/riscv/riscv-common.cc | 2 +-
 gcc/config/riscv/arch-canonicalize  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)


base-commit: a60228404f2ac11b5eb66270037ff3fa6bf948e5
-- 
2.34.1

[PATCH v2 1/1] RISC-V: Fix canonical extension order (K and J)

[Tsukasa OI via Gcc-patches]

This commit fixes canonical extension order to follow the RISC-V ISA
Manual draft-20210402-1271737 or later.

gcc/ChangeLog:

* common/config/riscv/riscv-common.cc (riscv_supported_std_ext):
Fix "K" extension prefix to be placed before "J".
* config/riscv/arch-canonicalize: Likewise.

Signed-off-by: Tsukasa OI 
---
 gcc/common/config/riscv/riscv-common.cc | 2 +-
 gcc/config/riscv/arch-canonicalize  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index 1501242e296..0b0ec2c4ec5 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -594,7 +594,7 @@ riscv_subset_list::lookup (const char *subset, int 
major_version,
 static const char *
 riscv_supported_std_ext (void)
 {
-  return "mafdqlcbjktpvn";
+  return "mafdqlcbkjtpvn";
 }
 
 /* Parsing subset version.
diff --git a/gcc/config/riscv/arch-canonicalize 
b/gcc/config/riscv/arch-canonicalize
index 41bab69193c..71b2232b29e 100755
--- a/gcc/config/riscv/arch-canonicalize
+++ b/gcc/config/riscv/arch-canonicalize
@@ -32,7 +32,7 @@ import itertools
 from functools import reduce
 
 SUPPORTED_ISA_SPEC = ["2.2", "20190608", "20191213"]
-CANONICAL_ORDER = "imafdgqlcbjktpvn"
+CANONICAL_ORDER = "imafdgqlcbkjtpvn"
 LONG_EXT_PREFIXES = ['z', 's', 'h', 'x']
 
 #
-- 
2.34.1

Re: [PATCH 1/1] RISC-V: Fix canonical extension order (K and J)

[Tsukasa OI via Gcc-patches]

On 2022/05/19 12:40, Nelson Chu wrote:
> Seems like gcc and llvm have already committed this patch, so LGTM, committed.

Sorry, the same change is applied to LLVM but not yet on GCC (because I
forgot to add "Signed-off-by" line).  I sent PATCH v2 to gcc-patches
today so that would be okay.  On PATCH v2, I made the same change to
gcc/config/riscv/arch-canonicalize script (not just
gcc/common/config/riscv/riscv-common.cc).



Thanks,
Tsukasa

> 
> Thanks
> Nelson
> 
> On Mon, Apr 25, 2022 at 11:53 AM Palmer Dabbelt  wrote:
>>
>> On Mon, 28 Mar 2022 17:12:55 PDT (-0700), Palmer Dabbelt wrote:
>>> On Mon, 28 Mar 2022 06:12:01 PDT (-0700), binut...@sourceware.org wrote:
 This commit fixes canonical extension order to follow the RISC-V ISA
 Manual draft-20210402-1271737 or later.

 bfd/ChangeLog:

  * elfxx-riscv.c (riscv_recognized_prefixed_ext): Fix "K" extension
  prefix to be placed before "J".
 ---
  bfd/elfxx-riscv.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/bfd/elfxx-riscv.c b/bfd/elfxx-riscv.c
 index cb2cc146c04..1219a7b44d4 100644
 --- a/bfd/elfxx-riscv.c
 +++ b/bfd/elfxx-riscv.c
 @@ -1338,7 +1338,7 @@ riscv_recognized_prefixed_ext (const char *ext)
  }

  /* Canonical order for single letter extensions.  */
 -static const char riscv_ext_canonical_order[] = "eigmafdqlcbjktpvn";
 +static const char riscv_ext_canonical_order[] = "eigmafdqlcbkjtpvn";

  /* Array is used to compare the orders of standard extensions quickly.  */
  static int riscv_ext_order[26] = {0};
>>>
>>> Looks like this was just a bug in binutils: K went from being
>>> unspecified to specified in 271737 ("Define canonical location of K
>>> extension in ISA string"), thus it was never allowed at that other bit
>>> position.
>>>
>>> It looks like GCC also has this wrong, which sort of doubles the
>>> headache: now we've got this odd coupling between the GCC version and
>>> binutils version.  I'm not sure what the right thing is to do here:
>>> certainly rejecting the valid ISA string should be fixed, but I think we
>>> might need to accept the invalid one for compatibility reasons.  That'll
>>> be a headache to implement, though, so I'm not sure it's worth it.
>>>
>>> Maybe someone has a clever solution to this one?
>>
>> After seeing the GCC patch go by, I think the clever solution here is to
>> just say that we never accepted any J stuff in the first place so it's
>> not a compatibility break.
> 

Re: [PATCH] [x86_64]: Zhaoxin lujiazui enablement

[Uros Bizjak via Gcc-patches]

On Tue, May 17, 2022 at 11:34 AM Mayshao-oc  wrote:
>
> > On Tue, May 17, 2022 at 5:15 AM mayshao  wrote:
> >> Hi Uros:
> >> This patch fix Zhaoxin CPU vendor ID detection problem and add 
> >> zhaoxin "lujiazui" processor support.
> >> Currently gcc can't recognize Zhaoxin CPU(vendor ID "CentaurHauls" 
> >> and "Shanghai") if user use -march=native option, which is confusing for 
> >> users.
> >> This patch enables -march=native in zhaoxin family 7th processor 
> >> and -march/-mtune=lujiazui, costs and tunning are set according to the 
> >> characteristics of the processor.We add a new md file to describe lujiazui 
> >> pipeline.
> >> Testing:
> >> Bootstrap is ok, and no regressions for i386/x86-64 testsuite.
> >> Ok for master?
> >> Background:
> >> Related Zhaoxin linux kernel patch can be found at:
> >> https://lore.kernel.org/lkml/01042674b2f741b2aed1f797359bd...@zhaoxin.com/
> >> Related Zhaoxin glibc patch can be found at:
> >> https://sourceware.org/git/?p=glibc.git;a=commit;h=32ac0b988466785d6e3cc1dffc364bb26fc63193
> >> gcc/ChangeLog:
> > The entries below are suspiciously empty - please fill in the details.
>
> Sorry for forgetting this. Update patch. Thanks.
>
> * common/config/i386/cpuinfo.h (get_zhaoxin_cpu): Detect
> the specific type of Zhaoxin CPU, and return Zhaoxin CPU name.
> (cpu_indicator_init): Handle Zhaoxin processors.
> * common/config/i386/i386-common.cc: Add lujiazui.
> * common/config/i386/i386-cpuinfo.h (enum processor_vendor): Add
> VENDOR_ZHAOXIN.
> (enum processor_types): Add ZHAOXIN_FAM7H.
> (enum processor_subtypes): Add ZHAOXIN_FAM7H_LUJIAZUI.
> * config.gcc: Add lujiazui.
> * config/i386/cpuid.h (signature_SHANGHAI_ebx): Add
> Signatures for zhaoxin
> (signature_SHANGHAI_ecx): Ditto.
> (signature_SHANGHAI_edx): Ditto.
> * config/i386/driver-i386.cc (host_detect_local_cpu): Let
> -march=native recognize lujiazui processors.
> * config/i386/i386-c.cc (ix86_target_macros_internal): Add lujiazui.
> * config/i386/i386-options.cc (m_LUJIAZUI): New_definition.
> * config/i386/i386.h (enum processor_type): Ditto.
> * config/i386/i386.md: Add lujiazui.
> * config/i386/x86-tune-costs.h (struct processor_costs): Add
> lujiazui costs.
> * config/i386/x86-tune-sched.cc (ix86_issue_rate): Add lujiazui.
> (ix86_adjust_cost): Ditto.
> * config/i386/x86-tune.def (X86_TUNE_SCHEDULE): Add lujiazui tunnings.
> (X86_TUNE_PARTIAL_REG_DEPENDENCY): Ditto.
> (X86_TUNE_SSE_PARTIAL_REG_DEPENDENCY): Ditto.
> (X86_TUNE_SSE_PARTIAL_REG_FP_CONVERTS_DEPENDENCY): Ditto.
> (X86_TUNE_SSE_PARTIAL_REG_CONVERTS_DEPENDENCY): Ditto.
> (X86_TUNE_MOVX): Ditto.
> (X86_TUNE_MEMORY_MISMATCH_STALL): Ditto.
> (X86_TUNE_FUSE_CMP_AND_BRANCH_32): Ditto.
> (X86_TUNE_FUSE_CMP_AND_BRANCH_64): Ditto.
> (X86_TUNE_FUSE_CMP_AND_BRANCH_SOFLAGS): Ditto.
> (X86_TUNE_FUSE_ALU_AND_BRANCH): Ditto.
> (X86_TUNE_ACCUMULATE_OUTGOING_ARGS): Ditto.
> (X86_TUNE_USE_LEAVE): Ditto.
> (X86_TUNE_PUSH_MEMORY): Ditto.
> (X86_TUNE_LCP_STALL): Ditto.
> (X86_TUNE_USE_INCDEC): Ditto.
> (X86_TUNE_INTEGER_DFMODE_MOVES): Ditto.
> (X86_TUNE_OPT_AGU): Ditto.
> (X86_TUNE_PREFER_KNOWN_REP_MOVSB_STOSB): Ditto.
> (X86_TUNE_MISALIGNED_MOVE_STRING_PRO_EPILOGUES): Ditto.
> (X86_TUNE_USE_SAHF): Ditto.
> (X86_TUNE_USE_BT): Ditto.
> (X86_TUNE_AVOID_FALSE_DEP_FOR_BMI): Ditto.
> (X86_TUNE_ONE_IF_CONV_INSN): Ditto.
> (X86_TUNE_AVOID_MFENCE): Ditto.
> (X86_TUNE_EXPAND_ABS): Ditto.
> (X86_TUNE_USE_SIMODE_FIOP): Ditto.
> (X86_TUNE_USE_FFREEP): Ditto.
> (X86_TUNE_EXT_80387_CONSTANTS): Ditto.
> (X86_TUNE_SSE_UNALIGNED_LOAD_OPTIMAL): Ditto.
> (X86_TUNE_SSE_UNALIGNED_STORE_OPTIMAL): Ditto.
> (X86_TUNE_SSE_TYPELESS_STORES): Ditto.
> (X86_TUNE_SSE_LOAD0_BY_PXOR): Ditto.
> * doc/extend.texi: Add details about lujiazui.
> * doc/invoke.texi: Add details about lujiazui.
> * config/i386/lujiazui.md: Introduce lujiazui cpu and include new md file.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/funcspec-56.inc: Test -arch=lujiauzi and -tune=lujiazui.
> * g++.target/i386/mv32.C: Ditto.

The patch looks good to me (However, I didn't review the .md file in details).

BTW: The approval applies to the technical part, the legal part should
be handled by someone else - if it is still needed after the project
was changed from copyright assignment style to the developer's
certificate of origin style.

Also, can you handle the commit by yourself, or should I do it for you?

Thanks,
Uros.

>
> >> * common/config/i386/cpuinfo.h (get_zhaoxin_cpu):
> >> (cpu_indicator_init):
> >> * common/config/i386/i386-common.cc:
> >> * common/config/i386/i386-cpuinfo.h (enum processor_vendor):
> >> (enum processor_types):
> >> (enum processor_subtypes):
> >> * config.gcc:
> >> * config/i386/cpuid.h (signature_SHANGHAI_ebx):
> >> (signature_SHANGHAI_ecx):
> >> (signature_SHANGHAI_edx):
> >> * config/i386/driver-i386.cc (host_detect_local_cpu):
> >> * config/i386/i386-c.cc (ix86_target_

Re: [PATCH] Add divide by zero side effect.

[Alexander Monakov via Gcc-patches]

On Fri, 20 May 2022, Richard Biener wrote:

> > > > I suggest 'deduce', 'deduction', 'deducing a range'. What the code is 
> > > > actually
> > > > doing is deducing that 'b' in 'a / b' cannot be zero. Function in GCC 
> > > > might be
> > > > called like 'deduce_ranges_from_stmt'.
> > >
> > > So how would you call determining the range of 'c' from the ranges of
> > > 'a' and 'b', isn't that 'deduction' as well?
> >
> > Kind of, yes, but for this sort of forward inference I imagine you're 
> > already
> > using 'propagate [ranges through a stmt]', like in 'value range 
> > propagation'.
> >
> > If you'd like to avoid 'propagate'/'deduce' asymmetry, I could suggest
> > 'forward inference' / 'backward inference', but I like it a bit less.
> 
> Hmm, maybe "guarantees" - if the stmt executed (without traps) then
> it's guaranteed that the divisor isn't zero.  I've almost said 'assertions'
> but then asserts also have separate meanings, not to mention ASSERT_EXPR
> as currently used by the old-style VRP.

I feel the word 'assumptions' captures that nicely.

Alexander

Re: [PATCH] rs6000: add support for sanitizers on FreeBSD

[Piotr Kubaj]

Ping.

FreeBSD has already enabled sanitizers in its base system in 
https://cgit.freebsd.org/src/commit/?id=f5024381ac16ba43d37a8bd32d54c27f6a6afa66
The upstream (LLVM) patch was reviewed by a couple of people already.

Our llvm-devel port also has sanitizers enabled by default since 
https://cgit.freebsd.org/ports/commit/?id=70d8d9125c9f5b1da36b134408b3d580a39f1aa8

On 22-05-15 12:57:13, Piotr Kubaj wrote:
> GCC's f732bf6a603721f61102a08ad2d023c7c2670870 merged LLVM's
> 315d792130258a9b7250494be8d002ebb427b08f, which added sanitizers support for
> PowerPC on FreeBSD, so this commit only enables building it.
> 
> Enabled sanitizers are the same as on powerpc*-*-linux*.
> 
> libsanitizer
>   * configure.tgt: add powerpc*-*-freebsd* as supported
> ---
>  libsanitizer/ChangeLog | 4 
>  libsanitizer/configure.tgt | 2 ++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/libsanitizer/ChangeLog b/libsanitizer/ChangeLog
> index 52050be9476..17cc395aea1 100644
> --- a/libsanitizer/ChangeLog
> +++ b/libsanitizer/ChangeLog
> @@ -1,3 +1,7 @@
> +2022-05-15  Piotr Kubaj 
> +
> + * configure.tgt: add powerpc*-*-freebsd*
> +
>  2022-05-05  Martin Liska  
>  
>   * LOCAL_PATCHES: Update.
> diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
> index fb89df4935c..affe8964f84 100644
> --- a/libsanitizer/configure.tgt
> +++ b/libsanitizer/configure.tgt
> @@ -31,6 +31,8 @@ case "${target}" in
>   TSAN_TARGET_DEPENDENT_OBJECTS=tsan_rtl_amd64.lo
>   fi
>   ;;
> +  powerpc*-*-freebsd*)
> + ;;
>powerpc*-*-linux*)
>   if test x$ac_cv_sizeof_void_p = x8; then
>   TSAN_SUPPORTED=yes
> -- 
> 2.36.0
> 


signature.asc
Description: PGP signature

[PATCH V2]rs6000: Store complicated constant into pool

[Jiufu Guo via Gcc-patches]

Hi,

And after some discussions in the previous review:
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591509.html
This patch simply updates the rtx_cost hook to accurate cost on
constant by using 'COSTS_N_INSNS' with 'num_insns_constant'.  This
could avoid CSE eliminate constant loading.

Compare with previous patch, this patch update cost for prefixed
load('pld') slightly faster.

To set a constant to a reg, one way is building the constant through
instructions, like lis/ori/sldi...  Another way is loading it from
the constant pool through instruction 'ld'(or 'pld' for P10).

Loading a constant may need 2 instructions (or just 'pld' on P10),
and according to testing, if building the constant needs more than 2
instructions (or more than 1 instruction on P10), it is faster to load
it from constant pool.

This patch reduces the threshold of instruction number for storing
constant to pool and update cost for constant and mem accessing.

Bootstrap and regtest pass on ppc64le and ppc64.
Is this ok for trunk?


BR,
Jiufu


PR target/63281

gcc/ChangeLog:

* config/rs6000/rs6000.cc (rs6000_cannot_force_const_mem):
Exclude rtx with code 'HIGH'.
(rs6000_emit_move): Update threshold of const insn.
(rs6000_rtx_costs): Update cost of constant and mem.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/medium_offset.c: Update.
* gcc.target/powerpc/pr93012.c: Update.
* gcc.target/powerpc/pr63281.c: New test.


---
 gcc/config/rs6000/rs6000.cc   | 23 +++
 .../gcc.target/powerpc/medium_offset.c|  2 +-
 gcc/testsuite/gcc.target/powerpc/pr63281.c| 11 +
 gcc/testsuite/gcc.target/powerpc/pr93012.c|  2 +-
 4 files changed, 31 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr63281.c

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index cd291f93019..90c91a8e1ea 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -9706,8 +9706,9 @@ rs6000_init_stack_protect_guard (void)
 static bool
 rs6000_cannot_force_const_mem (machine_mode mode ATTRIBUTE_UNUSED, rtx x)
 {
-  if (GET_CODE (x) == HIGH
-  && GET_CODE (XEXP (x, 0)) == UNSPEC)
+  /* Exclude CONSTANT HIGH part.  e.g.
+ (high:DI (symbol_ref:DI ("var") [flags 0xc0] )).  */
+  if (GET_CODE (x) == HIGH)
 return true;
 
   /* A TLS symbol in the TOC cannot contain a sum.  */
@@ -11139,7 +11140,7 @@ rs6000_emit_move (rtx dest, rtx source, machine_mode 
mode)
&& FP_REGNO_P (REGNO (operands[0])))
   || !CONST_INT_P (operands[1])
   || (num_insns_constant (operands[1], mode)
-  > (TARGET_CMODEL != CMODEL_SMALL ? 3 : 2)))
+  > (TARGET_PREFIXED ? 1 : 2)))
   && !toc_relative_expr_p (operands[1], false, NULL, NULL)
   && (TARGET_CMODEL == CMODEL_SMALL
   || can_create_pseudo_p ()
@@ -22101,6 +22102,14 @@ rs6000_rtx_costs (rtx x, machine_mode mode, int 
outer_code,
 
 case CONST_DOUBLE:
 case CONST_WIDE_INT:
+  /* Set a const to reg, it may needs a few insns.  */
+  if (outer_code == SET)
+   {
+ *total = COSTS_N_INSNS (num_insns_constant (x, mode));
+ return true;
+   }
+  /* FALLTHRU */
+
 case CONST:
 case HIGH:
 case SYMBOL_REF:
@@ -22110,8 +22119,12 @@ rs6000_rtx_costs (rtx x, machine_mode mode, int 
outer_code,
 case MEM:
   /* When optimizing for size, MEM should be slightly more expensive
 than generating address, e.g., (plus (reg) (const)).
-L1 cache latency is about two instructions.  */
-  *total = !speed ? COSTS_N_INSNS (1) + 1 : COSTS_N_INSNS (2);
+L1 cache latency is about two instructions.
+For prefixed load (pld), we would set it slightly faster than
+than two instructions. */
+  *total = !speed
+? COSTS_N_INSNS (1) + 1
+: TARGET_PREFIXED ? COSTS_N_INSNS (2) - 1 : COSTS_N_INSNS (2);
   if (rs6000_slow_unaligned_access (mode, MEM_ALIGN (x)))
*total += COSTS_N_INSNS (100);
   return true;
diff --git a/gcc/testsuite/gcc.target/powerpc/medium_offset.c 
b/gcc/testsuite/gcc.target/powerpc/medium_offset.c
index f29eba08c38..4889e8fa8ec 100644
--- a/gcc/testsuite/gcc.target/powerpc/medium_offset.c
+++ b/gcc/testsuite/gcc.target/powerpc/medium_offset.c
@@ -1,7 +1,7 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target lp64 } */
 /* { dg-options "-O" } */
-/* { dg-final { scan-assembler-not "\\+4611686018427387904" } } */
+/* { dg-final { scan-assembler-times {\msldi|pld\M} 1 } } */
 
 static int x;
 
diff --git a/gcc/testsuite/gcc.target/powerpc/pr63281.c 
b/gcc/testsuite/gcc.target/powerpc/pr63281.c
new file mode 100644
index 000..469a8f64400
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr63281.c
@@ -0,0 +1,11 @@
+/* PR target/63

Re: [PATCH] rs6000: add support for sanitizers on FreeBSD

[Kewen.Lin via Gcc-patches]

Hi Piotr,

on 2022/5/23 05:36, Piotr Kubaj wrote:
> Ping.
> 
> FreeBSD has already enabled sanitizers in its base system in 
> https://cgit.freebsd.org/src/commit/?id=f5024381ac16ba43d37a8bd32d54c27f6a6afa66
> The upstream (LLVM) patch was reviewed by a couple of people already.
> 
> Our llvm-devel port also has sanitizers enabled by default since 
> https://cgit.freebsd.org/ports/commit/?id=70d8d9125c9f5b1da36b134408b3d580a39f1aa8
> 

Thanks for the patch.  I think you also need to introduce a new subtarget
ASAN_SHADOW_OFFSET for freebsd?  One reference case is the
SUBTARGET_SHADOW_OFFSET in freebsd.h under i386.

BR,
Kewen

> On 22-05-15 12:57:13, Piotr Kubaj wrote:
>> GCC's f732bf6a603721f61102a08ad2d023c7c2670870 merged LLVM's
>> 315d792130258a9b7250494be8d002ebb427b08f, which added sanitizers support for
>> PowerPC on FreeBSD, so this commit only enables building it.
>>
>> Enabled sanitizers are the same as on powerpc*-*-linux*.
>>
>> libsanitizer
>>  * configure.tgt: add powerpc*-*-freebsd* as supported
>> ---
>>  libsanitizer/ChangeLog | 4 
>>  libsanitizer/configure.tgt | 2 ++
>>  2 files changed, 6 insertions(+)
>>
>> diff --git a/libsanitizer/ChangeLog b/libsanitizer/ChangeLog
>> index 52050be9476..17cc395aea1 100644
>> --- a/libsanitizer/ChangeLog
>> +++ b/libsanitizer/ChangeLog
>> @@ -1,3 +1,7 @@
>> +2022-05-15  Piotr Kubaj 
>> +
>> +* configure.tgt: add powerpc*-*-freebsd*
>> +
>>  2022-05-05  Martin Liska  
>>  
>>  * LOCAL_PATCHES: Update.
>> diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
>> index fb89df4935c..affe8964f84 100644
>> --- a/libsanitizer/configure.tgt
>> +++ b/libsanitizer/configure.tgt
>> @@ -31,6 +31,8 @@ case "${target}" in
>>  TSAN_TARGET_DEPENDENT_OBJECTS=tsan_rtl_amd64.lo
>>  fi
>>  ;;
>> +  powerpc*-*-freebsd*)
>> +;;
>>powerpc*-*-linux*)
>>  if test x$ac_cv_sizeof_void_p = x8; then
>>  TSAN_SUPPORTED=yes
>> -- 
>> 2.36.0
>>

Re: [committed] wwwdocs: gcc-12: Fix HTML around RISC-V entries

[Kito Cheng via Gcc-patches]

Thank you, Gerald :)

On Sun, May 22, 2022 at 6:29 AM Gerald Pfeifer  wrote:
>
> I'm not sure when that sneaked in (and it predates that last entry),
> but  followed by  is one too many in any case. :-)
>
> Pushed.
>
> Gerald
> ---
>  htdocs/gcc-12/changes.html | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
> index 3b94378e..ae03c3c6 100644
> --- a/htdocs/gcc-12/changes.html
> +++ b/htdocs/gcc-12/changes.html
> @@ -820,7 +820,6 @@ function Multiply (S1, S2 : Sign) return Sign is
>  libstdc++ no longer attempts to detect built-in atomics.
> Distributions that have out-of-tree workarounds for
> -latomic should check their ABIs again.
> -  
>  
>
>  
> --
> 2.36.0
>

Re: [PATCH v2 1/1] RISC-V: Fix canonical extension order (K and J)

[Kito Cheng via Gcc-patches]

Pushed, thanks!

On Sun, May 22, 2022 at 5:30 PM Tsukasa OI via Gcc-patches
 wrote:
>
> This commit fixes canonical extension order to follow the RISC-V ISA
> Manual draft-20210402-1271737 or later.
>
> gcc/ChangeLog:
>
> * common/config/riscv/riscv-common.cc (riscv_supported_std_ext):
> Fix "K" extension prefix to be placed before "J".
> * config/riscv/arch-canonicalize: Likewise.
>
> Signed-off-by: Tsukasa OI 
> ---
>  gcc/common/config/riscv/riscv-common.cc | 2 +-
>  gcc/config/riscv/arch-canonicalize  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/common/config/riscv/riscv-common.cc 
> b/gcc/common/config/riscv/riscv-common.cc
> index 1501242e296..0b0ec2c4ec5 100644
> --- a/gcc/common/config/riscv/riscv-common.cc
> +++ b/gcc/common/config/riscv/riscv-common.cc
> @@ -594,7 +594,7 @@ riscv_subset_list::lookup (const char *subset, int 
> major_version,
>  static const char *
>  riscv_supported_std_ext (void)
>  {
> -  return "mafdqlcbjktpvn";
> +  return "mafdqlcbkjtpvn";
>  }
>
>  /* Parsing subset version.
> diff --git a/gcc/config/riscv/arch-canonicalize 
> b/gcc/config/riscv/arch-canonicalize
> index 41bab69193c..71b2232b29e 100755
> --- a/gcc/config/riscv/arch-canonicalize
> +++ b/gcc/config/riscv/arch-canonicalize
> @@ -32,7 +32,7 @@ import itertools
>  from functools import reduce
>
>  SUPPORTED_ISA_SPEC = ["2.2", "20190608", "20191213"]
> -CANONICAL_ORDER = "imafdgqlcbjktpvn"
> +CANONICAL_ORDER = "imafdgqlcbkjtpvn"
>  LONG_EXT_PREFIXES = ['z', 's', 'h', 'x']
>
>  #
> --
> 2.34.1
>

[PATCH] PR tree-optimization/105668: Provide RTL expansion for VEC_COND_EXPR.

[Roger Sayle]

This resolves PR tree-optimization/105668, a P1 ice-on-valid regression
triggered by my recent patch to add a vec_cmpeqv1tiv1ti define_expand
to the i386 backend.  The existence of this optab currently leads GCC
to incorrectly assume the existence of a corresponding vcond_mask for
V1TImode.

I believe the best solution (of the three possible fixes) is to allow
gimple_expand_vec_cond_expr to fail (return NULL) when a suitable optab
to generate a IFN_VCOND_MASK isn't available, but instead allow RTL
expansion to provide a default implementation using vector mode logic
operations.  On x86_64, the equivalent of a pblend can be generated in
three instructions using pand, pandn and pxor.  In fact, this fallback
implementation is already used in ix86_expand_sse_movcc when the -march
doesn't provide a suitable instruction.  This patch provides that
functionality to all targets in the middle-end, allowing the vectorizer(s)
to safely assume support for VEC_COND_EXPR (when the target has suitable
vector logic instructions).

I should point out (for the record) that the new expand_vec_cond_expr
function in expr.cc is very different from the function of the same name
removed by Matin Liska in June 2020.
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547097.html
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=502d63b6d6141597bb18fd23c8
7736a1b384cf8f
That function simply expanded the vcond_mask optab and failed if it
wasn't available, which is currently the task of the gimple-isel pass.
The implementation here is a traditional RTL expander, sythesizing the
desired vector conditional move using bit-wise XOR and AND instructions
of the mask vector.

At some point in the future, gimple-isel could be enhanced to consider
alternative vector modes, as a V1TI blend/vec_cond_expr may be implemented
using V2DI, V4SI, V8HI or V16QI.  Alas, I couldn't figure out how to
conveniently iterate over the desired modes, so this enhancement is left
for a follow-up patch.

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32} with
no new failures.  Ok for mainline?


2022-05-23  Roger Sayle  

gcc/ChangeLog
PR tree-optimization/105668
* expr.cc (expand_vec_cond_expr): New function to expand
VEC_COND_EXPR using vector mode logical instructions.
(expand_expr_real_2) : Call the above.
* gimple-isel.cc (gimple_expand_vec_cond_expr): Instead of
asserting, retun NULL when the target's get_vcond_mask_icode
returns CODE_FOR_nothing.

gcc/testsuite/ChangeLog
PR tree-optimization/105668
* gcc.target/i386/pr105668.c: New test case.

Roger
--

diff --git a/gcc/expr.cc b/gcc/expr.cc
index 7197996..d130c4f 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -8931,6 +8931,53 @@ expand_expr_divmod (tree_code code, machine_mode mode, 
tree treeop0,
   return expand_divmod (mod_p, code, mode, op0, op1, target, unsignedp);
 }
 
+/* Expand VEC_COND_EXPR TARGET = OP0 ? OP1 : OP2 as a sequence of
+   logical operations, typically (OP0 & OP1) | (~OP0 & OP2).  */
+
+static rtx
+expand_vec_cond_expr (machine_mode mode, rtx op0, rtx op1, rtx op2,
+ rtx target)
+{
+  if (rtx_equal_p (op1, op2))
+return op1;
+
+  if (op0 == CONST0_RTX (GET_MODE (op0)))
+return op2;
+  if (vector_all_ones_operand (op0, GET_MODE (op0)))
+return op1;
+
+  if (mode != GET_MODE (op0))
+op0 = convert_modes (mode, GET_MODE (op0), op0, true);
+
+  if (op2 == CONST0_RTX (mode))
+{
+  if (vector_all_ones_operand (op1, mode))
+   return op0;
+  return expand_simple_binop (mode, AND, op0, op1,
+ target, 1, OPTAB_DIRECT);
+}
+  else if (op1 == CONST0_RTX (mode))
+{
+  rtx tmp = expand_simple_unop (mode, NOT, op0, target, 1);
+  if (vector_all_ones_operand (op2, mode))
+   return tmp;
+  return expand_simple_binop (mode, AND, tmp, op2,
+ target, 1, OPTAB_DIRECT);
+}
+  else if (vector_all_ones_operand (op1, mode))
+return expand_simple_binop (mode, IOR, op0, op2,
+   target, 1, OPTAB_DIRECT);
+
+  rtx tmp1 = expand_simple_binop (mode, XOR, op1, op2,
+ NULL_RTX, 1, OPTAB_DIRECT);
+  rtx tmp2 = expand_simple_binop (mode, AND, op0, tmp1,
+ NULL_RTX, 1, OPTAB_DIRECT);
+  return expand_simple_binop (mode, XOR, tmp2, op2,
+ target, 1, OPTAB_DIRECT);
+}
+
+/* sepops variant of expand_expr_real.  */
+
 rtx
 expand_expr_real_2 (sepops ops, rtx target, machine_mode tmode,
enum expand_modifier modifier)
@@ -10302,6 +10349,12 @@ expand_expr_real_2 (sepops ops, rtx target, 
machine_mode tmode,
   expand_operands (treeop0, treeop1, NULL_RTX, &op0, &op1, modifier);
   return expand_vec_series_expr (mode, op0, op1, target);
 
+case VEC_COND_EXPR:
+  op0 = expan