[PATCH]: Fix static-pie on Hurd target

2022-10-23 Thread Samuel Thibault via Gcc-patches
When linking with -static-pie, we need to use rcrt0.o (and grcrt0.o for
-pg). Also, set static:crt0.o before pie:Scrt1.o, otherwise -static -pie
fails to link with Scrt1.o due to missing _DYNAMIC symbol.

Also, -static-pie needs crtbeginS.o (otherwise it contains a relocation
in read-only .text).

And eventually, when HAVE_LD_PIE is not defined, there is no reason to
include the pie case

gcc/ChangeLog

* gcc/config/i386/gnu.h (STARTFILE_SPEC): Add static-pie cases
and fix -static -pie case.

---
 gcc/config/i386/gnu.h |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/config/i386/gnu.h b/gcc/config/i386/gnu.h
index fb8d69a97d8..7d7bfa7da7b 100644
--- a/gcc/config/i386/gnu.h
+++ b/gcc/config/i386/gnu.h
@@ -27,12 +27,12 @@ along with GCC.  If not, see .
 #undef STARTFILE_SPEC
 #if defined HAVE_LD_PIE
 #define STARTFILE_SPEC \
-  "%{!shared: 
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}}
 \
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+  "%{!shared: 
%{pg|p|profile:%{static-pie:grcrt0.o%s;static:gcrt0.o%s;:gcrt1.o%s};static-pie:rcrt0.o%s;static:crt0.o%s;pie:Scrt1.o%s;:crt1.o%s}}
 \
+   crti.o%s 
%{static:crtbeginT.o%s;shared|pie|static-pie:crtbeginS.o%s;:crtbegin.o%s}"
 #else
 #define STARTFILE_SPEC \
   "%{!shared: 
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};static:crt0.o%s;:crt1.o%s}} \
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+   crti.o%s %{static:crtbeginT.o%s;shared:crtbeginS.o%s;:crtbegin.o%s}"
 #endif
 
 #ifdef TARGET_LIBC_PROVIDES_SSP


Re: [PATCH] d: Remove D-specific version definitions from target headers

2022-10-23 Thread ibuclaw--- via Gcc-patches
> On 17/10/2022 20:08 CEST Iain Buclaw  wrote:
> 
>  
> Hi,
> 
> This splits up the targetdm sources so that each file only handles one
> target platform.
> 
> Having all logic kept in the headers means that they could become out of
> sync when a new target is added (loongarch*-*-linux*) or accidentally
> broken if some headers in tm_file are omitted or changed about.
> 
> There might be an open bikeshed question as to appropriate names for
> some of the platform sources (kfreebsd-d.cc or kfreebsd-gnu-d.cc).
> 
> Bootstrapped and regression tested on x86_64-linux-gnu, and also built
> i686-cygwin, i686-gnu, i686-kfreebsd-gnu, i686-kopensolaris-gnu,
> x86_64-cygwin, x86_64-w64-mingw32 cross compilers, the dumps of all
> predefined version identifiers remain correct in all configurations.
> 
> OK?
> 

Ping?

I'll apply this tomorrow, but there is a general open question about whether 
taking logic out of target headers and putting it in config.gcc is the right 
approach moving forward for non C/C++ front-ends.  This is also relevant for 
Rust, which initially put all their target support definitions in headers, and 
have since removed the entire tangled mess that created.

Regards,
Iain.


Re: Ping (c,c++): Handling of main() function for freestanding

2022-10-23 Thread Arsen Arsenović via Gcc-patches
On Friday, 21 October 2022 23:02:02 CEST Joseph Myers wrote:
> I have no objections to the C changes.

Great!  Thanks for the review.  I don't have push rights currently, so I 
must ask that someone else pushes this patch for me.

Have a great day!
-- 
Arsen Arsenović


signature.asc
Description: This is a digitally signed message part.


RE: [PATCH] [X86_64]: Enable support for next generation AMD Zen4 CPU

2022-10-23 Thread Kumar, Venkataramanan via Gcc-patches
[AMD Official Use Only - General]

Hi Richi and Jakub

> -Original Message-
> From: Jakub Jelinek 
> Sent: Saturday, October 22, 2022 10:41 PM
> To: Richard Biener 
> Cc: Kumar, Venkataramanan ; Joshi,
> Tejas Sanjay ; gcc-patches@gcc.gnu.org;
> honza.hubi...@gmail.com
> Subject: Re: [PATCH] [X86_64]: Enable support for next generation AMD
> Zen4 CPU
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> On Fri, Oct 21, 2022 at 01:51:55PM +0200, Richard Biener via Gcc-patches
> wrote:
> > > > > BTW: Perhaps znver1.md is not the right filename anymore, since
> > > > > it hosts
> > > > all four Zen schedulers.
> > > >
> > > > I have renamed the file to znver.md in this revision, PFA.
> > > > Thank you for the review, we will push it for trunk if we don't
> > > > get any further comments.
> > >
> > > I have pushed the patch on behalf of Tejas.
> >
> > This grew insn-automata.cc from 201502 lines to 639968 lines and the
> > build of the automata (genautomata) to several minutes in my dev tree.
>
> Yeah, in my unoptimized non-bootstrapped development tree genautomata
> now takes over 12 minutes on a fast box, that is simply not acceptable.

Thank you for notifying us.

tejassanjay.jo...@amd.com has posted a patch for review to fix this (as per 
Honza's comments).
Ref: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604144.html

Sorry for the inconvenience caused.

Regards,
Venkat.

>
> Jakub



[PATCH] [PR tree-optimization/107365] Check HONOR_NANS instead of flag_finite_math_only in frange:verify_range.

2022-10-23 Thread Aldy Hernandez via Gcc-patches
[Jakub and other FP experts, would this be OK, or am I missing
something?]

Vax does not seem to have !flag_finite_math_only, but float_type_node
does not HONOR_NANS.  The check in frange::verify_range dependend on
flag_finite_math_only, which is technically not correct since
frange::set_varying() checks HONOR_NANS instead of
flag_finite_math_only.

I'm actually getting tired of flag_finite_math_only and
!flag_finite_math_only discrepancies in the selftests (Vax and rx-elf
come to mind).  I think we should just test both alternatives in the
selftests as in this patch.

We could also check flag_finite_math_only=0 with a float_type_node
that does not HONOR_NANs, but I have no idea how to twiddle
FLOAT_MODE_FORMAT temporarily, and that may be over thinking it.

How does this look?

PR tree-optimization/107365

gcc/ChangeLog:

* value-range.cc (frange::verify_range): Predicate NAN check in
VARYING range on HONOR_NANS instead of flag_finite_math_only.
(range_tests_floats): Same.
(range_tests_floats_various): New.
(range_tests): Call range_tests_floats_various.
---
 gcc/value-range.cc | 33 +
 1 file changed, 25 insertions(+), 8 deletions(-)

diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index d779e9819e2..d8ee6ec0d0f 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -720,13 +720,13 @@ frange::verify_range ()
   gcc_checking_assert (!m_type);
   return;
 case VR_VARYING:
-  if (flag_finite_math_only)
-   gcc_checking_assert (!m_pos_nan && !m_neg_nan);
-  else
-   gcc_checking_assert (m_pos_nan && m_neg_nan);
   gcc_checking_assert (m_type);
   gcc_checking_assert (frange_val_is_min (m_min, m_type));
   gcc_checking_assert (frange_val_is_max (m_max, m_type));
+  if (HONOR_NANS (m_type))
+   gcc_checking_assert (m_pos_nan && m_neg_nan);
+  else
+   gcc_checking_assert (!m_pos_nan && !m_neg_nan);
   return;
 case VR_RANGE:
   gcc_checking_assert (m_type);
@@ -3957,10 +3957,9 @@ range_tests_floats ()
   // A range of [-INF,+INF] is actually VARYING if no other properties
   // are set.
   r0 = frange_float ("-Inf", "+Inf");
-  if (r0.maybe_isnan ())
-ASSERT_TRUE (r0.varying_p ());
+  ASSERT_TRUE (r0.varying_p ());
   // ...unless it has some special property...
-  if (!flag_finite_math_only)
+  if (HONOR_NANS (r0.type ()))
 {
   r0.clear_nan ();
   ASSERT_FALSE (r0.varying_p ());
@@ -4041,6 +4040,24 @@ range_tests_floats ()
 }
 }
 
+// Run floating range tests for various combinations of NAN and INF
+// support.
+
+static void
+range_tests_floats_various ()
+{
+  int save_finite_math_only = flag_finite_math_only;
+
+  // Test -ffinite-math-only.
+  flag_finite_math_only = 1;
+  range_tests_floats ();
+  // Test -fno-finite-math-only.
+  flag_finite_math_only = 0;
+  range_tests_floats ();
+
+  flag_finite_math_only = save_finite_math_only;
+}
+
 void
 range_tests ()
 {
@@ -4049,7 +4066,7 @@ range_tests ()
   range_tests_int_range_max ();
   range_tests_strict_enum ();
   range_tests_nonzero_bits ();
-  range_tests_floats ();
+  range_tests_floats_various ();
   range_tests_misc ();
 }
 
-- 
2.37.3



[PATCH] c: If -fplan9-extensions, allow duplicate field declarations

2022-10-23 Thread Keegan Saunders via Gcc-patches
The Plan 9 compilers defer duplicate declaration checks until field
resolution time.  Further, there is a priority order of resolution such
that field lookups first match the name, then typedef'd names before
recursing into substructures.

This enables large portions of the Plan 9 userspace and kernel to be
compiled with GCC without modification.

gcc/c/ChangeLog:

* c-decl.cc (is_duplicate_field): Remove unused Plan 9 logic.
(detect_field_duplicates_hash): Likewise.
(detect_field_duplicates): If -fplan9-extensions, disable
duplicate field detection.
* c-typeck.cc (lookup_field_plan9): Implement the Plan 9 look up
  scheme.
(lookup_field): Likewise.

gcc/testsuite/ChangeLog:

* gcc.dg/anon-struct-13.c: Add duplicate fields.

Signed-off-by: Keegan Saunders 
---
 gcc/c/c-decl.cc   |  63 ++--
 gcc/c/c-typeck.cc | 101 --
 gcc/testsuite/gcc.dg/anon-struct-13.c |   9 +++
 3 files changed, 96 insertions(+), 77 deletions(-)

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 193e268f04e..539ad407f49 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -8538,41 +8538,7 @@ grokfield (location_t loc,
 static bool
 is_duplicate_field (tree x, tree y)
 {
-  if (DECL_NAME (x) != NULL_TREE && DECL_NAME (x) == DECL_NAME (y))
-return true;
-
-  /* When using -fplan9-extensions, an anonymous field whose name is a
- typedef can duplicate a field name.  */
-  if (flag_plan9_extensions
-  && (DECL_NAME (x) == NULL_TREE || DECL_NAME (y) == NULL_TREE))
-{
-  tree xt, xn, yt, yn;
-
-  xt = TREE_TYPE (x);
-  if (DECL_NAME (x) != NULL_TREE)
-   xn = DECL_NAME (x);
-  else if (RECORD_OR_UNION_TYPE_P (xt)
-  && TYPE_NAME (xt) != NULL_TREE
-  && TREE_CODE (TYPE_NAME (xt)) == TYPE_DECL)
-   xn = DECL_NAME (TYPE_NAME (xt));
-  else
-   xn = NULL_TREE;
-
-  yt = TREE_TYPE (y);
-  if (DECL_NAME (y) != NULL_TREE)
-   yn = DECL_NAME (y);
-  else if (RECORD_OR_UNION_TYPE_P (yt)
-  && TYPE_NAME (yt) != NULL_TREE
-  && TREE_CODE (TYPE_NAME (yt)) == TYPE_DECL)
-   yn = DECL_NAME (TYPE_NAME (yt));
-  else
-   yn = NULL_TREE;
-
-  if (xn != NULL_TREE && xn == yn)
-   return true;
-}
-
-  return false;
+  return DECL_NAME (x) != NULL_TREE && DECL_NAME (x) == DECL_NAME (y);
 }
 
 /* Subroutine of detect_field_duplicates: add the fields of FIELDLIST
@@ -8599,19 +8565,6 @@ detect_field_duplicates_hash (tree fieldlist,
 else if (RECORD_OR_UNION_TYPE_P (TREE_TYPE (x)))
   {
detect_field_duplicates_hash (TYPE_FIELDS (TREE_TYPE (x)), htab);
-
-   /* When using -fplan9-extensions, an anonymous field whose
-  name is a typedef can duplicate a field name.  */
-   if (flag_plan9_extensions
-   && TYPE_NAME (TREE_TYPE (x)) != NULL_TREE
-   && TREE_CODE (TYPE_NAME (TREE_TYPE (x))) == TYPE_DECL)
- {
-   tree xn = DECL_NAME (TYPE_NAME (TREE_TYPE (x)));
-   slot = htab->find_slot (xn, INSERT);
-   if (*slot)
- error ("duplicate member %q+D", TYPE_NAME (TREE_TYPE (x)));
-   *slot = xn;
- }
   }
 }
 
@@ -8639,6 +8592,11 @@ detect_field_duplicates (tree fieldlist)
 if (objc_detect_field_duplicates (false))
   return;
 
+  /* When using -fplan9-extensions, do not perform duplicate field
+ checks until a field look up is performed.  */
+  if (flag_plan9_extensions)
+   return;
+
   /* First, see if there are more than "a few" fields.
  This is trivially true if there are zero or one fields.  */
   if (!fieldlist || !DECL_CHAIN (fieldlist))
@@ -8658,14 +8616,7 @@ detect_field_duplicates (tree fieldlist)
   if (timeout > 0)
 {
   for (x = DECL_CHAIN (fieldlist); x; x = DECL_CHAIN (x))
-   /* When using -fplan9-extensions, we can have duplicates
-  between typedef names and fields.  */
-   if (DECL_NAME (x)
-   || (flag_plan9_extensions
-   && DECL_NAME (x) == NULL_TREE
-   && RECORD_OR_UNION_TYPE_P (TREE_TYPE (x))
-   && TYPE_NAME (TREE_TYPE (x)) != NULL_TREE
-   && TREE_CODE (TYPE_NAME (TREE_TYPE (x))) == TYPE_DECL))
+   if (DECL_NAME (x))
  {
for (y = fieldlist; y != x; y = TREE_CHAIN (y))
  if (is_duplicate_field (y, x))
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index f9190680a3c..97ffa329ba7 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -95,6 +95,7 @@ static int comp_target_types (location_t, tree, tree);
 static int function_types_compatible_p (const_tree, const_tree, bool *,
bool *);
 static int type_lists_compatible_p (const_tree, const_tree, bool *, bool *);
+static tree lookup_field_plan9 (tree, tree);
 static tree lookup_field (tree, tree);
 static int convert_arguments (location_t, vec,

[PATCH] Add -gcodeview option

2022-10-23 Thread Mark Harmstone
Both current lld and the next version of ld have an option -pdb, which
creates a PDB file which Microsoft's debuggers can use. This patch adds
a -gcodeview option, which passes this to the linker.

I do intend to expand this so it also creates the .debug$S and .debug$T
sections which would make this useful - I submitted patches for this a
while back, but they need to be rewritten to parse the DWARF DIEs rather
than using debug_hooks.

Clang also has -gcodeview, but AFAICS only uses it for .debug$S and
.debug$T, and doesn't use it for linker options (though IMO it probably
should).

---
 gcc/common.opt  | 4 
 gcc/doc/invoke.texi | 7 +++
 gcc/gcc.cc  | 4 
 gcc/opts.cc | 3 +++
 4 files changed, 18 insertions(+)

diff --git a/gcc/common.opt b/gcc/common.opt
index 8a0dafc522d..77103f961d8 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -3253,6 +3253,10 @@ gas-locview-support
 Common Driver Var(dwarf2out_as_locview_support)
 Assume assembler support for view in (DWARF2+) .loc directives.
 
+gcodeview
+Common Driver JoinedOrMissing
+Generate debug information in CodeView format.
+
 gcoff
 Common Driver WarnRemoved
 Does nothing.  Preserved for backward compatibility.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ff6c338bedb..2d29fd2611d 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -483,6 +483,7 @@ Objective-C and Objective-C++ Dialects}.
 -gstabs  -gstabs+  -gstrict-dwarf  -gno-strict-dwarf @gol
 -gas-loc-support  -gno-as-loc-support @gol
 -gas-locview-support  -gno-as-locview-support @gol
+-gcodeview @gol
 -gcolumn-info  -gno-column-info  -gdwarf32  -gdwarf64 @gol
 -gstatement-frontiers  -gno-statement-frontiers @gol
 -gvariable-location-views  -gno-variable-location-views @gol
@@ -10358,6 +10359,12 @@ assembler (GAS) to fail with an error.
 Produce debugging information in Alpha/VMS debug format (if that is
 supported).  This is the format used by DEBUG on Alpha/VMS systems.
 
+@item -gcodeview
+@opindex gcodeview
+Produce debugging information in CodeView debug format (if that is
+supported).  This is the format used by Microsoft Visual C++ on
+Windows.
+
 @item -g@var{level}
 @itemx -ggdb@var{level}
 @itemx -gstabs@var{level}
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index bb07cc244e3..2820f325282 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -4608,6 +4608,10 @@ driver_handle_option (struct gcc_options *opts,
   do_save = false;
   break;
 
+case OPT_gcodeview:
+  add_infile ("-pdb=", "*");
+  break;
+
 default:
   /* Various driver options need no special processing at this
 point, having been handled in a prescan above or being
diff --git a/gcc/opts.cc b/gcc/opts.cc
index 3a89da2dd03..e2633ee5439 100644
--- a/gcc/opts.cc
+++ b/gcc/opts.cc
@@ -3089,6 +3089,9 @@ common_handle_option (struct gcc_options *opts,
   set_debug_level (NO_DEBUG, 2, arg, opts, opts_set, loc);
   break;
 
+case OPT_gcodeview:
+  break;
+
 case OPT_gstabs:
 case OPT_gstabs_:
   set_debug_level (DBX_DEBUG, code == OPT_gstabs_, arg, opts, opts_set,
-- 
2.37.3



[PATCH] RISC-V: Fix REG_CLASS_CONTENTS.

2022-10-23 Thread juzhe . zhong
From: Ju-Zhe Zhong 

gcc/ChangeLog:

* config/riscv/riscv.h (enum reg_class): Fix ALL_REGS.

---
 gcc/config/riscv/riscv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
index acae68ebb2d..37363e975e1 100644
--- a/gcc/config/riscv/riscv.h
+++ b/gcc/config/riscv/riscv.h
@@ -516,7 +516,7 @@ enum reg_class
   { 0x, 0x, 0x, 0x0001 },  /* V0_REGS */   
\
   { 0x, 0x, 0x, 0xfffe },  /* VNoV0_REGS */
\
   { 0x, 0x, 0x, 0x },  /* V_REGS */
\
-  { 0x, 0x, 0x0003, 0x }   /* ALL_REGS */  
\
+  { 0x, 0x, 0x000f, 0x }   /* ALL_REGS */  
\
 }
 
 /* A C expression whose value is a register class containing hard
-- 
2.36.1



[PATCH] RISC-V: Support (set (mem) (const_poly_int)) handling and remove TI/TF.

2022-10-23 Thread juzhe . zhong
From: Ju-Zhe Zhong 

gcc/ChangeLog:

* config/riscv/riscv-vector-switch.def (ENTRY): Remove TI/TF.
* config/riscv/riscv.cc (riscv_legitimize_move): Support (set (mem) 
(const_poly_int)).

---
 gcc/config/riscv/riscv-vector-switch.def |  4 
 gcc/config/riscv/riscv.cc| 14 ++
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/gcc/config/riscv/riscv-vector-switch.def 
b/gcc/config/riscv/riscv-vector-switch.def
index cacfccb6d29..ee8ebd5f1cc 100644
--- a/gcc/config/riscv/riscv-vector-switch.def
+++ b/gcc/config/riscv/riscv-vector-switch.def
@@ -155,10 +155,6 @@ ENTRY (VNx4DF, TARGET_VECTOR_FP64)
 ENTRY (VNx2DF, TARGET_VECTOR_FP64)
 ENTRY (VNx1DF, TARGET_VECTOR_FP64)
 
-/* SEW = 128. Disable all of them.  */
-ENTRY (VNx2TI, false)
-ENTRY (VNx2TF, false)
-
 #undef TARGET_VECTOR_FP32
 #undef TARGET_VECTOR_FP64
 #undef ENTRY
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 90a39047dd7..f7694ba043c 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -1958,6 +1958,20 @@ riscv_legitimize_move (machine_mode mode, rtx dest, rtx 
src)
 {
   if (CONST_POLY_INT_P (src))
 {
+  /*
+   Handle:
+ (insn 183 182 184 6 (set (mem:QI (plus:DI (reg/f:DI 156)
+ (const_int 96 [0x60])) [0  S1 A8])
+ (const_poly_int:QI [8, 8]))
+   "../../../../riscv-gcc/libgcc/unwind-dw2.c":1579:3 -1 (nil))
+  */
+  if (MEM_P (dest))
+   {
+ rtx tmp = gen_reg_rtx (mode);
+ emit_move_insn (tmp, src);
+ emit_move_insn (dest, tmp);
+ return true;
+   }
   poly_int64 value = rtx_to_poly_int64 (src);
   if (!value.is_constant () && !TARGET_VECTOR)
{
-- 
2.36.1



Re: [PATCH] RISC-V: Support (set (mem) (const_poly_int)) handling and remove TI/TF.

2022-10-23 Thread juzhe.zh...@rivai.ai
I made a mistake in this patch. I mixed 2 commits into a single patch.
Sorry about that. Please ignore this patch. Thanks.



juzhe.zh...@rivai.ai
 
From: juzhe.zhong
Date: 2022-10-24 09:53
To: gcc-patches
CC: kito.cheng; palmer; Ju-Zhe Zhong
Subject: [PATCH] RISC-V: Support (set (mem) (const_poly_int)) handling and 
remove TI/TF.
From: Ju-Zhe Zhong 
 
gcc/ChangeLog:
 
* config/riscv/riscv-vector-switch.def (ENTRY): Remove TI/TF.
* config/riscv/riscv.cc (riscv_legitimize_move): Support (set (mem) 
(const_poly_int)).
 
---
gcc/config/riscv/riscv-vector-switch.def |  4 
gcc/config/riscv/riscv.cc| 14 ++
2 files changed, 14 insertions(+), 4 deletions(-)
 
diff --git a/gcc/config/riscv/riscv-vector-switch.def 
b/gcc/config/riscv/riscv-vector-switch.def
index cacfccb6d29..ee8ebd5f1cc 100644
--- a/gcc/config/riscv/riscv-vector-switch.def
+++ b/gcc/config/riscv/riscv-vector-switch.def
@@ -155,10 +155,6 @@ ENTRY (VNx4DF, TARGET_VECTOR_FP64)
ENTRY (VNx2DF, TARGET_VECTOR_FP64)
ENTRY (VNx1DF, TARGET_VECTOR_FP64)
-/* SEW = 128. Disable all of them.  */
-ENTRY (VNx2TI, false)
-ENTRY (VNx2TF, false)
-
#undef TARGET_VECTOR_FP32
#undef TARGET_VECTOR_FP64
#undef ENTRY
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 90a39047dd7..f7694ba043c 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -1958,6 +1958,20 @@ riscv_legitimize_move (machine_mode mode, rtx dest, rtx 
src)
{
   if (CONST_POLY_INT_P (src))
 {
+  /*
+ Handle:
+   (insn 183 182 184 6 (set (mem:QI (plus:DI (reg/f:DI 156)
+   (const_int 96 [0x60])) [0  S1 A8])
+   (const_poly_int:QI [8, 8]))
+ "../../../../riscv-gcc/libgcc/unwind-dw2.c":1579:3 -1 (nil))
+  */
+  if (MEM_P (dest))
+ {
+   rtx tmp = gen_reg_rtx (mode);
+   emit_move_insn (tmp, src);
+   emit_move_insn (dest, tmp);
+   return true;
+ }
   poly_int64 value = rtx_to_poly_int64 (src);
   if (!value.is_constant () && !TARGET_VECTOR)
{
-- 
2.36.1
 


[PATCH] RISC-V: Support (set (mem) (const_poly_int))

2022-10-23 Thread juzhe . zhong
From: Ju-Zhe Zhong 

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_legitimize_move): Support (set (mem) 
(const_poly_int)).

---
 gcc/config/riscv/riscv.cc | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 90a39047dd7..f7694ba043c 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -1958,6 +1958,20 @@ riscv_legitimize_move (machine_mode mode, rtx dest, rtx 
src)
 {
   if (CONST_POLY_INT_P (src))
 {
+  /*
+   Handle:
+ (insn 183 182 184 6 (set (mem:QI (plus:DI (reg/f:DI 156)
+ (const_int 96 [0x60])) [0  S1 A8])
+ (const_poly_int:QI [8, 8]))
+   "../../../../riscv-gcc/libgcc/unwind-dw2.c":1579:3 -1 (nil))
+  */
+  if (MEM_P (dest))
+   {
+ rtx tmp = gen_reg_rtx (mode);
+ emit_move_insn (tmp, src);
+ emit_move_insn (dest, tmp);
+ return true;
+   }
   poly_int64 value = rtx_to_poly_int64 (src);
   if (!value.is_constant () && !TARGET_VECTOR)
{
-- 
2.36.1



[PATCH] RISC-V: Remove unused TI/TF vector modes.

2022-10-23 Thread juzhe . zhong
From: Ju-Zhe Zhong 

gcc/ChangeLog:

* config/riscv/riscv-vector-switch.def (ENTRY): Remove unused TI/TF 
vector modes.

---
 gcc/config/riscv/riscv-vector-switch.def | 4 
 1 file changed, 4 deletions(-)

diff --git a/gcc/config/riscv/riscv-vector-switch.def 
b/gcc/config/riscv/riscv-vector-switch.def
index cacfccb6d29..ee8ebd5f1cc 100644
--- a/gcc/config/riscv/riscv-vector-switch.def
+++ b/gcc/config/riscv/riscv-vector-switch.def
@@ -155,10 +155,6 @@ ENTRY (VNx4DF, TARGET_VECTOR_FP64)
 ENTRY (VNx2DF, TARGET_VECTOR_FP64)
 ENTRY (VNx1DF, TARGET_VECTOR_FP64)
 
-/* SEW = 128. Disable all of them.  */
-ENTRY (VNx2TI, false)
-ENTRY (VNx2TF, false)
-
 #undef TARGET_VECTOR_FP32
 #undef TARGET_VECTOR_FP64
 #undef ENTRY
-- 
2.36.1



[PATCH] RISC-V: Support load/store in mov pattern for RVV modes.

2022-10-23 Thread juzhe . zhong
From: Ju-Zhe Zhong 

---
 gcc/config.gcc|   2 +-
 gcc/config/riscv/constraints.md   |  22 +
 gcc/config/riscv/predicates.md|  23 ++
 gcc/config/riscv/riscv-protos.h   |  14 +
 gcc/config/riscv/riscv-v.cc   | 180 
 .../riscv/riscv-vector-builtins-bases.cc  |  14 +-
 gcc/config/riscv/riscv.cc |  67 ++-
 gcc/config/riscv/riscv.h  |   2 +
 gcc/config/riscv/riscv.md |   9 +-
 gcc/config/riscv/t-riscv  |   4 +
 gcc/config/riscv/vector-iterators.md  |  58 +++
 gcc/config/riscv/vector.md| 279 -
 .../gcc.target/riscv/rvv/base/mov-1.c | 179 
 .../gcc.target/riscv/rvv/base/mov-10.c| 385 ++
 .../gcc.target/riscv/rvv/base/mov-11.c| 385 ++
 .../gcc.target/riscv/rvv/base/mov-12.c| 159 
 .../gcc.target/riscv/rvv/base/mov-13.c|  14 +
 .../gcc.target/riscv/rvv/base/mov-2.c | 153 +++
 .../gcc.target/riscv/rvv/base/mov-3.c | 127 ++
 .../gcc.target/riscv/rvv/base/mov-4.c | 101 +
 .../gcc.target/riscv/rvv/base/mov-5.c |  66 +++
 .../gcc.target/riscv/rvv/base/mov-6.c |  53 +++
 .../gcc.target/riscv/rvv/base/mov-7.c |  13 +
 .../gcc.target/riscv/rvv/base/mov-8.c |  96 +
 .../gcc.target/riscv/rvv/base/mov-9.c |  44 ++
 25 files changed, 2421 insertions(+), 28 deletions(-)
 create mode 100644 gcc/config/riscv/riscv-v.cc
 create mode 100644 gcc/config/riscv/vector-iterators.md
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-10.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-11.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-12.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-13.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-4.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-5.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-6.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-7.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-8.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-9.c

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 3826ae42803..0232e572a99 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -515,7 +515,7 @@ pru-*-*)
;;
 riscv*)
cpu_type=riscv
-   extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o 
riscv-shorten-memrefs.o riscv-selftests.o"
+   extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o 
riscv-shorten-memrefs.o riscv-selftests.o riscv-v.o"
extra_objs="${extra_objs} riscv-vector-builtins.o 
riscv-vector-builtins-shapes.o riscv-vector-builtins-bases.o"
d_target_objs="riscv-d.o"
extra_headers="riscv_vector.h"
diff --git a/gcc/config/riscv/constraints.md b/gcc/config/riscv/constraints.md
index 8997284f32e..951dcc52d6b 100644
--- a/gcc/config/riscv/constraints.md
+++ b/gcc/config/riscv/constraints.md
@@ -128,3 +128,25 @@
   "POLY_INT"
   (and (match_code "const_poly_int")
(match_test "known_eq (rtx_to_poly_int64 (op), 
BYTES_PER_RISCV_VECTOR)")))
+
+(define_constraint "vu"
+  "A undefined vector value."
+  (and (match_code "unspec")
+   (match_test "XINT (op, 1) == UNSPEC_VUNDEF")))
+
+(define_constraint "vi"
+  "A vector 5-bit signed immediate."
+  (and (match_code "const_vector")
+   (match_test "riscv_vector::const_vec_all_same_in_range_p (op, -16, 
15)")))
+
+(define_constraint "Wc0"
+  "@internal
+ A constraint that matches a vector of immediate all zeros."
+ (and (match_code "const_vector")
+  (match_test "op == CONST0_RTX (GET_MODE (op))")))
+
+(define_constraint "Wc1"
+  "@internal
+ A constraint that matches a vector of immediate all ones."
+ (and (match_code "const_vector")
+  (match_test "op == CONSTM1_RTX (GET_MODE (op))")))
diff --git a/gcc/config/riscv/predicates.md b/gcc/config/riscv/predicates.md
index 5e149b3a95f..e2bfafe8150 100644
--- a/gcc/config/riscv/predicates.md
+++ b/gcc/config/riscv/predicates.md
@@ -262,3 +262,26 @@
 
return true;
 })
+
+;; Predicates for the V extension.
+(define_special_predicate "vector_length_operand"
+  (ior (match_operand 0 "pmode_register_operand")
+   (match_operand 0 "const_csr_operand")))
+
+(define_predicate "reg_or_mem_operand"
+  (ior (match_operand 0 "register_operand")
+   (match_operand 0 "memory_operand")))
+
+(define_predicate "vector_move_operand"
+  (ior (match_operand 0 "nonimmediate_operand")
+   (match_code "const_vector")))
+
+(define_predicate "vector_mask_operand"
+  (ior (match_operand 0 "register_operand")
+

Re: [PATCH] RISC-V: Support (set (mem) (const_poly_int))

2022-10-23 Thread Andrew Pinski via Gcc-patches
On Sun, Oct 23, 2022 at 7:04 PM  wrote:
>
> From: Ju-Zhe Zhong 
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_legitimize_move): Support (set (mem) 
> (const_poly_int)).
>
> ---
>  gcc/config/riscv/riscv.cc | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 90a39047dd7..f7694ba043c 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -1958,6 +1958,20 @@ riscv_legitimize_move (machine_mode mode, rtx dest, 
> rtx src)
>  {
>if (CONST_POLY_INT_P (src))
>  {
> +  /*
> +   Handle:
> + (insn 183 182 184 6 (set (mem:QI (plus:DI (reg/f:DI 156)
> + (const_int 96 [0x60])) [0  S1 A8])
> + (const_poly_int:QI [8, 8]))
> +   "../../../../riscv-gcc/libgcc/unwind-dw2.c":1579:3 -1 (nil))
> +  */
> +  if (MEM_P (dest))
> +   {
> + rtx tmp = gen_reg_rtx (mode);
> + emit_move_insn (tmp, src);
> + emit_move_insn (dest, tmp);

Couldn't you just use force_reg here instead of the above?
Something like:
emit_move_insn (dest, force_reg (mode, src));

Thanks,
Andrew Pinski

> + return true;
> +   }
>poly_int64 value = rtx_to_poly_int64 (src);
>if (!value.is_constant () && !TARGET_VECTOR)
> {
> --
> 2.36.1
>


Re: [PATCH] RISC-V: Fix REG_CLASS_CONTENTS.

2022-10-23 Thread Kito Cheng via Gcc-patches
Committed, thanks for the fix!

On Mon, Oct 24, 2022 at 9:39 AM  wrote:
>
> From: Ju-Zhe Zhong 
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.h (enum reg_class): Fix ALL_REGS.
>
> ---
>  gcc/config/riscv/riscv.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
> index acae68ebb2d..37363e975e1 100644
> --- a/gcc/config/riscv/riscv.h
> +++ b/gcc/config/riscv/riscv.h
> @@ -516,7 +516,7 @@ enum reg_class
>{ 0x, 0x, 0x, 0x0001 },  /* V0_REGS */ 
>   \
>{ 0x, 0x, 0x, 0xfffe },  /* VNoV0_REGS */  
>   \
>{ 0x, 0x, 0x, 0x },  /* V_REGS */  
>   \
> -  { 0x, 0x, 0x0003, 0x }   /* ALL_REGS */
>   \
> +  { 0x, 0x, 0x000f, 0x }   /* ALL_REGS */
>   \
>  }
>
>  /* A C expression whose value is a register class containing hard
> --
> 2.36.1
>


[PATCH] RISC-V: Replace CONSTEXPR with constexpr

2022-10-23 Thread juzhe . zhong
From: Ju-Zhe Zhong 

Move away from the pre-C++11 compatibility macro CONSTEXPR.
This patch is inspired by aarch64:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603974.html.

gcc/ChangeLog:

* config/riscv/riscv-vector-builtins-bases.cc: Replace CONSTEXPR
with constexpr throughout.
* config/riscv/riscv-vector-builtins-shapes.cc (SHAPE): Likewise.
* config/riscv/riscv-vector-builtins.cc (struct 
registered_function_hasher): Likewise.
* config/riscv/riscv-vector-builtins.h (struct rvv_arg_type_info): 
Likewise.

---
 gcc/config/riscv/riscv-vector-builtins-bases.cc  |  4 ++--
 gcc/config/riscv/riscv-vector-builtins-shapes.cc |  2 +-
 gcc/config/riscv/riscv-vector-builtins.cc| 14 +++---
 gcc/config/riscv/riscv-vector-builtins.h |  2 +-
 4 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.cc 
b/gcc/config/riscv/riscv-vector-builtins-bases.cc
index 231b63a610d..713a7566e29 100644
--- a/gcc/config/riscv/riscv-vector-builtins-bases.cc
+++ b/gcc/config/riscv/riscv-vector-builtins-bases.cc
@@ -84,8 +84,8 @@ public:
   }
 };
 
-static CONSTEXPR const vsetvl vsetvl_obj;
-static CONSTEXPR const vsetvl vsetvlmax_obj;
+static constexpr const vsetvl vsetvl_obj;
+static constexpr const vsetvl vsetvlmax_obj;
 namespace bases {
 const function_base *const vsetvl = &vsetvl_obj;
 const function_base *const vsetvlmax = &vsetvlmax_obj;
diff --git a/gcc/config/riscv/riscv-vector-builtins-shapes.cc 
b/gcc/config/riscv/riscv-vector-builtins-shapes.cc
index 24fc1c02341..14c59690c06 100644
--- a/gcc/config/riscv/riscv-vector-builtins-shapes.cc
+++ b/gcc/config/riscv/riscv-vector-builtins-shapes.cc
@@ -71,7 +71,7 @@ build_all (function_builder &b, const function_group_info 
&group)
 /* Declare the function shape NAME, pointing it to an instance
of class _def.  */
 #define SHAPE(DEF, VAR) \
-  static CONSTEXPR const DEF##_def VAR##_obj; \
+  static constexpr const DEF##_def VAR##_obj; \
   namespace shapes { const function_shape *const VAR = &VAR##_obj; }
 
 /* Base class for for build.  */
diff --git a/gcc/config/riscv/riscv-vector-builtins.cc 
b/gcc/config/riscv/riscv-vector-builtins.cc
index dc410788c99..caeb97211f9 100644
--- a/gcc/config/riscv/riscv-vector-builtins.cc
+++ b/gcc/config/riscv/riscv-vector-builtins.cc
@@ -88,7 +88,7 @@ struct registered_function_hasher : 
nofree_ptr_hash
 };
 
 /* Static information about each RVV type.  */
-static CONSTEXPR const vector_type_info vector_types[] = {
+static constexpr const vector_type_info vector_types[] = {
 #define DEF_RVV_TYPE(NAME, NCHARS, ABI_NAME, ARGS...)  
\
   {#NAME, #ABI_NAME, "u" #NCHARS #ABI_NAME},
 #include "riscv-vector-builtins.def"
@@ -123,23 +123,23 @@ static const rvv_type_info i_ops[] = {
 #include "riscv-vector-builtins-types.def"
   {NUM_VECTOR_TYPES, 0}};
 
-static CONSTEXPR const rvv_arg_type_info rvv_arg_type_info_end
+static constexpr const rvv_arg_type_info rvv_arg_type_info_end
   = rvv_arg_type_info (NUM_BASE_TYPES);
 
 /* A list of args for size_t func (void) function.  */
-static CONSTEXPR const rvv_arg_type_info void_args[]
+static constexpr const rvv_arg_type_info void_args[]
   = {rvv_arg_type_info (RVV_BASE_void), rvv_arg_type_info_end};
 
 /* A list of args for size_t func (size_t) function.  */
-static CONSTEXPR const rvv_arg_type_info size_args[]
+static constexpr const rvv_arg_type_info size_args[]
   = {rvv_arg_type_info (RVV_BASE_size), rvv_arg_type_info_end};
 
 /* A list of none preds that will be registered for intrinsic functions.  */
-static CONSTEXPR const predication_type_index none_preds[]
+static constexpr const predication_type_index none_preds[]
   = {PRED_TYPE_none, NUM_PRED_TYPES};
 
 /* A static operand information for size_t func (void) function registration. 
*/
-static CONSTEXPR const rvv_op_info i_none_size_void_ops
+static constexpr const rvv_op_info i_none_size_void_ops
   = {i_ops,/* Types */
  OP_TYPE_none, /* Suffix */
  rvv_arg_type_info (RVV_BASE_size), /* Return type */
@@ -147,7 +147,7 @@ static CONSTEXPR const rvv_op_info i_none_size_void_ops
 
 /* A static operand information for size_t func (size_t) function registration.
  */
-static CONSTEXPR const rvv_op_info i_none_size_size_ops
+static constexpr const rvv_op_info i_none_size_size_ops
   = {i_ops,/* Types */
  OP_TYPE_none, /* Suffix */
  rvv_arg_type_info (RVV_BASE_size), /* Return type */
diff --git a/gcc/config/riscv/riscv-vector-builtins.h 
b/gcc/config/riscv/riscv-vector-builtins.h
index 425da12326c..e5636e23a7c 100644
--- a/gcc/config/riscv/riscv-vector-builtins.h
+++ b/gcc/config/riscv/riscv-vector-builtins.h
@@ -171,7 +171,7 @@ struct rvv_builtin_suffixes
 /* RVV Builtin argument information.  */
 struct rvv_arg_type_info
 {
-  CONSTEXPR rvv_arg_type_info (rvv_base_type base_type_in)
+

Re: [PATCH] RISC-V: Remove unused TI/TF vector modes.

2022-10-23 Thread Kito Cheng via Gcc-patches
Committed, thanks :)

On Mon, Oct 24, 2022 at 10:06 AM  wrote:
>
> From: Ju-Zhe Zhong 
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vector-switch.def (ENTRY): Remove unused TI/TF 
> vector modes.
>
> ---
>  gcc/config/riscv/riscv-vector-switch.def | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv-vector-switch.def 
> b/gcc/config/riscv/riscv-vector-switch.def
> index cacfccb6d29..ee8ebd5f1cc 100644
> --- a/gcc/config/riscv/riscv-vector-switch.def
> +++ b/gcc/config/riscv/riscv-vector-switch.def
> @@ -155,10 +155,6 @@ ENTRY (VNx4DF, TARGET_VECTOR_FP64)
>  ENTRY (VNx2DF, TARGET_VECTOR_FP64)
>  ENTRY (VNx1DF, TARGET_VECTOR_FP64)
>
> -/* SEW = 128. Disable all of them.  */
> -ENTRY (VNx2TI, false)
> -ENTRY (VNx2TF, false)
> -
>  #undef TARGET_VECTOR_FP32
>  #undef TARGET_VECTOR_FP64
>  #undef ENTRY
> --
> 2.36.1
>


Re: Re: [PATCH] RISC-V: Support (set (mem) (const_poly_int))

2022-10-23 Thread juzhe.zh...@rivai.ai
Address comments. Fix it soon.



juzhe.zh...@rivai.ai
 
From: Andrew Pinski
Date: 2022-10-24 10:14
To: juzhe.zhong
CC: gcc-patches; kito.cheng
Subject: Re: [PATCH] RISC-V: Support (set (mem) (const_poly_int))
On Sun, Oct 23, 2022 at 7:04 PM  wrote:
>
> From: Ju-Zhe Zhong 
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_legitimize_move): Support (set (mem) 
> (const_poly_int)).
>
> ---
>  gcc/config/riscv/riscv.cc | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 90a39047dd7..f7694ba043c 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -1958,6 +1958,20 @@ riscv_legitimize_move (machine_mode mode, rtx dest, 
> rtx src)
>  {
>if (CONST_POLY_INT_P (src))
>  {
> +  /*
> +   Handle:
> + (insn 183 182 184 6 (set (mem:QI (plus:DI (reg/f:DI 156)
> + (const_int 96 [0x60])) [0  S1 A8])
> + (const_poly_int:QI [8, 8]))
> +   "../../../../riscv-gcc/libgcc/unwind-dw2.c":1579:3 -1 (nil))
> +  */
> +  if (MEM_P (dest))
> +   {
> + rtx tmp = gen_reg_rtx (mode);
> + emit_move_insn (tmp, src);
> + emit_move_insn (dest, tmp);
 
Couldn't you just use force_reg here instead of the above?
Something like:
emit_move_insn (dest, force_reg (mode, src));
 
Thanks,
Andrew Pinski
 
> + return true;
> +   }
>poly_int64 value = rtx_to_poly_int64 (src);
>if (!value.is_constant () && !TARGET_VECTOR)
> {
> --
> 2.36.1
>
 


Re: [PATCH] RISC-V: Replace CONSTEXPR with constexpr

2022-10-23 Thread Kito Cheng via Gcc-patches
Committed, thanks!

On Mon, Oct 24, 2022 at 10:21 AM  wrote:
>
> From: Ju-Zhe Zhong 
>
> Move away from the pre-C++11 compatibility macro CONSTEXPR.
> This patch is inspired by aarch64:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603974.html.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vector-builtins-bases.cc: Replace CONSTEXPR
> with constexpr throughout.
> * config/riscv/riscv-vector-builtins-shapes.cc (SHAPE): Likewise.
> * config/riscv/riscv-vector-builtins.cc (struct 
> registered_function_hasher): Likewise.
> * config/riscv/riscv-vector-builtins.h (struct rvv_arg_type_info): 
> Likewise.
>
> ---
>  gcc/config/riscv/riscv-vector-builtins-bases.cc  |  4 ++--
>  gcc/config/riscv/riscv-vector-builtins-shapes.cc |  2 +-
>  gcc/config/riscv/riscv-vector-builtins.cc| 14 +++---
>  gcc/config/riscv/riscv-vector-builtins.h |  2 +-
>  4 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.cc 
> b/gcc/config/riscv/riscv-vector-builtins-bases.cc
> index 231b63a610d..713a7566e29 100644
> --- a/gcc/config/riscv/riscv-vector-builtins-bases.cc
> +++ b/gcc/config/riscv/riscv-vector-builtins-bases.cc
> @@ -84,8 +84,8 @@ public:
>}
>  };
>
> -static CONSTEXPR const vsetvl vsetvl_obj;
> -static CONSTEXPR const vsetvl vsetvlmax_obj;
> +static constexpr const vsetvl vsetvl_obj;
> +static constexpr const vsetvl vsetvlmax_obj;
>  namespace bases {
>  const function_base *const vsetvl = &vsetvl_obj;
>  const function_base *const vsetvlmax = &vsetvlmax_obj;
> diff --git a/gcc/config/riscv/riscv-vector-builtins-shapes.cc 
> b/gcc/config/riscv/riscv-vector-builtins-shapes.cc
> index 24fc1c02341..14c59690c06 100644
> --- a/gcc/config/riscv/riscv-vector-builtins-shapes.cc
> +++ b/gcc/config/riscv/riscv-vector-builtins-shapes.cc
> @@ -71,7 +71,7 @@ build_all (function_builder &b, const function_group_info 
> &group)
>  /* Declare the function shape NAME, pointing it to an instance
> of class _def.  */
>  #define SHAPE(DEF, VAR) \
> -  static CONSTEXPR const DEF##_def VAR##_obj; \
> +  static constexpr const DEF##_def VAR##_obj; \
>namespace shapes { const function_shape *const VAR = &VAR##_obj; }
>
>  /* Base class for for build.  */
> diff --git a/gcc/config/riscv/riscv-vector-builtins.cc 
> b/gcc/config/riscv/riscv-vector-builtins.cc
> index dc410788c99..caeb97211f9 100644
> --- a/gcc/config/riscv/riscv-vector-builtins.cc
> +++ b/gcc/config/riscv/riscv-vector-builtins.cc
> @@ -88,7 +88,7 @@ struct registered_function_hasher : 
> nofree_ptr_hash
>  };
>
>  /* Static information about each RVV type.  */
> -static CONSTEXPR const vector_type_info vector_types[] = {
> +static constexpr const vector_type_info vector_types[] = {
>  #define DEF_RVV_TYPE(NAME, NCHARS, ABI_NAME, ARGS...)
>   \
>{#NAME, #ABI_NAME, "u" #NCHARS #ABI_NAME},
>  #include "riscv-vector-builtins.def"
> @@ -123,23 +123,23 @@ static const rvv_type_info i_ops[] = {
>  #include "riscv-vector-builtins-types.def"
>{NUM_VECTOR_TYPES, 0}};
>
> -static CONSTEXPR const rvv_arg_type_info rvv_arg_type_info_end
> +static constexpr const rvv_arg_type_info rvv_arg_type_info_end
>= rvv_arg_type_info (NUM_BASE_TYPES);
>
>  /* A list of args for size_t func (void) function.  */
> -static CONSTEXPR const rvv_arg_type_info void_args[]
> +static constexpr const rvv_arg_type_info void_args[]
>= {rvv_arg_type_info (RVV_BASE_void), rvv_arg_type_info_end};
>
>  /* A list of args for size_t func (size_t) function.  */
> -static CONSTEXPR const rvv_arg_type_info size_args[]
> +static constexpr const rvv_arg_type_info size_args[]
>= {rvv_arg_type_info (RVV_BASE_size), rvv_arg_type_info_end};
>
>  /* A list of none preds that will be registered for intrinsic functions.  */
> -static CONSTEXPR const predication_type_index none_preds[]
> +static constexpr const predication_type_index none_preds[]
>= {PRED_TYPE_none, NUM_PRED_TYPES};
>
>  /* A static operand information for size_t func (void) function 
> registration. */
> -static CONSTEXPR const rvv_op_info i_none_size_void_ops
> +static constexpr const rvv_op_info i_none_size_void_ops
>= {i_ops,/* Types */
>   OP_TYPE_none, /* Suffix */
>   rvv_arg_type_info (RVV_BASE_size), /* Return type */
> @@ -147,7 +147,7 @@ static CONSTEXPR const rvv_op_info i_none_size_void_ops
>
>  /* A static operand information for size_t func (size_t) function 
> registration.
>   */
> -static CONSTEXPR const rvv_op_info i_none_size_size_ops
> +static constexpr const rvv_op_info i_none_size_size_ops
>= {i_ops,/* Types */
>   OP_TYPE_none, /* Suffix */
>   rvv_arg_type_info (RVV_BASE_size), /* Return type */
> diff --git a/gcc/config/riscv/riscv-vector-builtins.h 
> b/gcc/config/riscv/riscv-vector-builtins.h
> index 425da12326c..e5636e23a7c 100644
> --- a

[PATCH] RISC-V: Support (set (mem) (const_poly_int))

2022-10-23 Thread juzhe . zhong
From: Ju-Zhe Zhong 

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_legitimize_move): Adjust using force_reg.

---
 gcc/config/riscv/riscv.cc | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 98374a922d1..1fd34f6ae8d 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -1967,9 +1967,7 @@ riscv_legitimize_move (machine_mode mode, rtx dest, rtx 
src)
   */
   if (MEM_P (dest))
{
- rtx tmp = gen_reg_rtx (mode);
- emit_move_insn (tmp, src);
- emit_move_insn (dest, tmp);
+ emit_move_insn (dest, force_reg (mode, src));
  return true;
}
   poly_int64 value = rtx_to_poly_int64 (src);
-- 
2.36.1



[PATCH] ix86: Suggest unroll factor for loop vectorization

2022-10-23 Thread Cui,Lili via Gcc-patches
Hi Hongtao,

This patch introduces function finish_cost and 
determine_suggested_unroll_factor for x86 backend, to make it be
able to suggest the unroll factor for a given loop being vectorized.
Referring to aarch64, RS6000 backends and basing on the analysis on
SPEC2017 performance evaluation results.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

OK for trunk?



With this patch, SPEC2017 performance evaluation results on
ICX/CLX/ADL/Znver3 are listed below:

For single copy:
  - ICX: 549.fotonik3d_r +6.2%, the others are neutral
  - CLX: 549.fotonik3d_r +1.9%, the others are neutral
  - ADL: 549.fotonik3d_r +4.5%, the others are neutral
  - Znver3: 549.fotonik3d_r +4.8%, the others are neutral

For multi-copy:
  - ADL: 549.fotonik3d_r +2.7%, the others are neutral

gcc/ChangeLog:

* config/i386/i386.cc (class ix86_vector_costs): Add new members
 m_nstmts, m_nloads m_nstores and determine_suggested_unroll_factor.
(ix86_vector_costs::add_stmt_cost): Update for m_nstores, m_nloads
and m_nstores.
(ix86_vector_costs::determine_suggested_unroll_factor): New function.
(ix86_vector_costs::finish_cost): Diito.
* config/i386/i386.opt:(x86-vect-unroll-limit): New parameter.
(x86-vect-unroll-min-ldst-threshold): Likewise.
(x86-vect-unroll-max-loop-size): Likewise.
* doc/invoke.texi: Document new parameter.

gcc/testsuite/ChangeLog:

* gcc.target/i386/cond_op_maxmin_b-1.c: Add -fno-unroll-loops.
* gcc.target/i386/cond_op_maxmin_ub-1.c: Ditto.
* gcc.target/i386/vect-alignment-peeling-1.c: Ditto.
* gcc.target/i386/vect-alignment-peeling-2.c: Ditto.
* gcc.target/i386/vect-reduc-1.c: Ditto.
---
 gcc/config/i386/i386.cc   | 106 ++
 gcc/config/i386/i386.opt  |  15 +++
 gcc/doc/invoke.texi   |  17 +++
 .../gcc.target/i386/cond_op_maxmin_b-1.c  |   2 +-
 .../gcc.target/i386/cond_op_maxmin_ub-1.c |   2 +-
 .../i386/vect-alignment-peeling-1.c   |   2 +-
 .../i386/vect-alignment-peeling-2.c   |   2 +-
 gcc/testsuite/gcc.target/i386/vect-reduc-1.c  |   2 +-
 8 files changed, 143 insertions(+), 5 deletions(-)

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index aeea26ef4be..a939354e55e 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -23336,6 +23336,17 @@ class ix86_vector_costs : public vector_costs
  stmt_vec_info stmt_info, slp_tree node,
  tree vectype, int misalign,
  vect_cost_model_location where) override;
+
+  unsigned int determine_suggested_unroll_factor (loop_vec_info);
+
+  void finish_cost (const vector_costs *) override;
+
+  /* Total number of vectorized stmts (loop only).  */
+  unsigned m_nstmts = 0;
+  /* Total number of loads (loop only).  */
+  unsigned m_nloads = 0;
+  /* Total number of stores (loop only).  */
+  unsigned m_nstores = 0;
 };
 
 /* Implement targetm.vectorize.create_costs.  */
@@ -23579,6 +23590,19 @@ ix86_vector_costs::add_stmt_cost (int count, 
vect_cost_for_stmt kind,
retval = (retval * 17) / 10;
 }
 
+  if (!m_costing_for_scalar
+  && is_a (m_vinfo)
+  && where == vect_body)
+{
+  m_nstmts += count;
+  if (kind == scalar_load || kind == vector_load
+ || kind == unaligned_load || kind == vector_gather_load)
+   m_nloads += count;
+  else if (kind == scalar_store || kind == vector_store
+  || kind == unaligned_store || kind == vector_scatter_store)
+   m_nstores += count;
+}
+
   m_costs[where] += retval;
 
   return retval;
@@ -23850,6 +23874,88 @@ ix86_loop_unroll_adjust (unsigned nunroll, class loop 
*loop)
   return nunroll;
 }
 
+unsigned int
+ix86_vector_costs::determine_suggested_unroll_factor (loop_vec_info loop_vinfo)
+{
+  class loop *loop = LOOP_VINFO_LOOP (loop_vinfo);
+
+  /* Don't unroll if it's specified explicitly not to be unrolled.  */
+  if (loop->unroll == 1
+  || (OPTION_SET_P (flag_unroll_loops) && !flag_unroll_loops)
+  || (OPTION_SET_P (flag_unroll_all_loops) && !flag_unroll_all_loops))
+return 1;
+
+  /* Don't unroll if there is no vectorized stmt.  */
+  if (m_nstmts == 0)
+return 1;
+
+  /* Don't unroll if vector size is zmm, since zmm throughput is lower than 
other
+ sizes.  */
+  if (GET_MODE_SIZE (loop_vinfo->vector_mode) == 64)
+return 1;
+
+  /* Calc the total number of loads and stores in the loop body.  */
+  unsigned int nstmts_ldst = m_nloads + m_nstores;
+
+  /* Don't unroll if loop body size big than threshold, the threshold
+ is a heuristic value inspired by param_max_unrolled_insns.  */
+  unsigned int uf = m_nstmts < (unsigned int)x86_vect_unroll_max_loop_size
+   ? ((unsigned int)x86_vect_unroll_max_loop_size / m_nstmts)
+   : 1;
+  uf = MIN ((unsigned int)x86_vect

Re: [PATCH] RISC-V: Support (set (mem) (const_poly_int))

2022-10-23 Thread Kito Cheng via Gcc-patches
Merged two changes into one patch, and committed to master :)

On Mon, Oct 24, 2022 at 10:28 AM  wrote:
>
> From: Ju-Zhe Zhong 
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_legitimize_move): Adjust using 
> force_reg.
>
> ---
>  gcc/config/riscv/riscv.cc | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 98374a922d1..1fd34f6ae8d 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -1967,9 +1967,7 @@ riscv_legitimize_move (machine_mode mode, rtx dest, rtx 
> src)
>*/
>if (MEM_P (dest))
> {
> - rtx tmp = gen_reg_rtx (mode);
> - emit_move_insn (tmp, src);
> - emit_move_insn (dest, tmp);
> + emit_move_insn (dest, force_reg (mode, src));
>   return true;
> }
>poly_int64 value = rtx_to_poly_int64 (src);
> --
> 2.36.1
>


[PATCH-2, rs6000] Reverse V8HI on Power8 by vector rotation [PR100866]

2022-10-23 Thread HAO CHEN GUI via Gcc-patches
Hi,
  This patch implements V8HI byte reverse on Power8 by vector rotation.
It should be effecient than orignial vector permute. The patch comes from
Xionghu's comments in PR. I just added a test case for it.

  Bootstrapped and tested on ppc64 Linux BE and LE with no regressions.
Is this okay for trunk? Any recommendations? Thanks a lot.



ChangeLog
2022-10-24  Xionghu Luo 

gcc/
PR target/100866
* config/rs6000/altivec.md: (*altivec_vrl): Named to...
(altivec_vrl): ...this.
* config/rs6000/vsx.md (revb_): Call vspltish and vrlh when
target is Power8 and mode is V8HI.

gcc/testsuite/
PR target/100866
* gcc.target/powerpc/pr100866-2.c: New.

patch.diff
diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 2c4940f2e21..84660073f32 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@ -1875,7 +1875,7 @@ (define_insn "altivec_vpkuum_direct"
 }
   [(set_attr "type" "vecperm")])

-(define_insn "*altivec_vrl"
+(define_insn "altivec_vrl"
   [(set (match_operand:VI2 0 "register_operand" "=v")
 (rotate:VI2 (match_operand:VI2 1 "register_operand" "v")
(match_operand:VI2 2 "register_operand" "v")))]
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index e226a93bbe5..34662a7252d 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -6092,12 +6092,21 @@ (define_expand "revb_"
 emit_insn (gen_p9_xxbr_ (operands[0], operands[1]));
   else
 {
-  /* Want to have the elements in reverse order relative
-to the endian mode in use, i.e. in LE mode, put elements
-in BE order.  */
-  rtx sel = swap_endian_selector_for_mode(mode);
-  emit_insn (gen_altivec_vperm_ (operands[0], operands[1],
-  operands[1], sel));
+  if (mode == V8HImode)
+   {
+ rtx splt = gen_reg_rtx (V8HImode);
+ emit_insn (gen_altivec_vspltish (splt, GEN_INT (8)));
+ emit_insn (gen_altivec_vrlh (operands[0], operands[1], splt));
+   }
+  else
+   {
+ /* Want to have the elements in reverse order relative
+to the endian mode in use, i.e. in LE mode, put elements
+in BE order.  */
+ rtx sel = swap_endian_selector_for_mode (mode);
+ emit_insn (gen_altivec_vperm_ (operands[0], operands[1],
+  operands[1], sel));
+   }
 }

   DONE;
diff --git a/gcc/testsuite/gcc.target/powerpc/pr100866-2.c 
b/gcc/testsuite/gcc.target/powerpc/pr100866-2.c
new file mode 100644
index 000..4357d1beb09
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr100866-2.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=power8" } */
+/* { dg-final { scan-assembler {\mvspltish\M} } } */
+/* { dg-final { scan-assembler {\mvrlh\M} } } */
+
+#include 
+
+vector unsigned short revb(vector unsigned short a)
+{
+   return vec_revb(a);
+}
+


Re: Adding a new thread model to GCC

2022-10-23 Thread LIU Hao via Gcc-patches

在 2022/10/21 20:34, i.nix...@autistici.org 写道:


got it...
anyway it seems logical to me the way I proposed :)




Below is a message forwarded from mingw-w64-public, elaborating the necessity 
of a new thread model.

As there are objections from other mingw-w64 developers, I am putting those patches against 
mingw-w64-crt on hold for now. Despite that, all threading facilities - mutexes, condition 
variables, once flags, etc. - are still fully functional within the mcf thread model.


In addition, I will keep maintaining my personal builds (from GCC 12 release branch) with these 
patches at https://gcc-mcf.lhmouse.com/.



 Forwarded Message 
在 2022/10/23 18:06, Jacek Caban 写道:
>
> Please, let's not do that. It's possible to fix existing implementations, we 
don't need to make
> things more complicated than they are.
>

Okay okay, I think I have to compose a thorough list of problems that we are facing at the moment, 
and had better have a permalink to the mailing list archive that I can reference elsewhere. I have 
been tired of repeating the same grounds of arguments again and again:



1. In a DLL, destructors of static objects and callbacks that are registered
with `atexit()`, are executed by `LdrShutdownProcess()`, after all the other
thread have been terminated `ZwTerminateProcessO(NULL, status)`. This means
that, if another thread has been terminated while holding a mutex, the mutex
can never get unlocked. If a destructor attempts to lock the same mutex,
deadlocks will occur. Destructors of executables do not suffer from this
issue, because they are executed before `RtlExitUserProcess()`.

Standard behavior: Static destructors and exit callbacks should be executed
while other threads are running. If another thread attempts to access a
destroyed object, the behavior is undefined; the user is responsible to
prevent this from happening, by joining or suspending it.


2. Following 1, in a DLL, static destructors and exit callbacks are still
invoked when `_Exit()` or `quick_exit()` is called.

Standard behavior: `_Exit()` should not perform any cleanup; not even open
files are flushed. `quick_exit()` shall invoke all quick-exit callbacks in
reverse order, then call `_Exit()`.


3. There is a use-after-free bug [1] about thread-local destructors. I suspect
this is caused by emutls, because GCC uses `__cxa_thread_atexit()` to
register thread-local destructors, which could interleave with
`emutls_destroy()`.

Standard behavior: This is not allowed to happen. mcfgthread solves this
issue by running thread-local destructors and thread-specific key
destructors as two separate passes [3].

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80816
[2] 
https://github.com/gcc-mirror/gcc/blob/f84e4fb44aa26b71fbc64e0532fd24d96e5caa3f/libgcc/emutls.c#L96
[3] 
https://github.com/lhmouse/mcfgthread/blob/63e034d375caf585e2921cd3455f1048feb2172d/src/xglobals.c#L249



4. In the win32 thread model, thread-specific key destructors are called at
process exit [4], after static destructors.

Standard behavior: They shall be called only when a thread exits, and the
associated thread-specific values are not a null pointer. They shall not be
called when a program terminates; instead, users are responsible for
deallocating such resources before calling `exit()`. This requirement is
missing in POSIX, but formally specified by ISO/IEC 9899:2017, as the 4th
paragraph in '7.26.6.1 The tss_create function'.

[4] 
https://github.com/mingw-w64/mingw-w64/blob/d0a034a04d312434b842c4869a8a900568d8db98/mingw-w64-crt/crt/tlsthrd.c#L134



5. Wait operations, of timed mutexes and condition variables, should take
absolute time points as `struct timespec`.

Standard behavior: Both POSIX and ISO C specifies them as such, while all
Windows APIs take relative durations as a 32-bit integer of milliseconds,
which can also easily get overflown.


--
Best regards,
LIU Hao


OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH] [PR24021] Implement PLUS_EXPR range-op entry for floats.

2022-10-23 Thread Aldy Hernandez via Gcc-patches
PING

On Mon, Oct 17, 2022 at 8:21 AM Aldy Hernandez  wrote:
>
> On Thu, Oct 13, 2022 at 7:57 PM Jakub Jelinek  wrote:
> >
> > On Thu, Oct 13, 2022 at 02:36:49PM +0200, Aldy Hernandez wrote:
> > > +// Like real_arithmetic, but round the result to INF if the operation
> > > +// produced inexact results.
> > > +//
> > > +// ?? There is still one problematic case, i387.  With
> > > +// -fexcess-precision=standard we perform most SF/DFmode arithmetic in
> > > +// XFmode (long_double_type_node), so that case is OK.  But without
> > > +// -mfpmath=sse, all the SF/DFmode computations are in XFmode
> > > +// precision (64-bit mantissa) and only occassionally rounded to
> > > +// SF/DFmode (when storing into memory from the 387 stack).  Maybe
> > > +// this is ok as well though it is just occassionally more precise. ??
> > > +
> > > +static void
> > > +frange_arithmetic (enum tree_code code, tree type,
> > > +REAL_VALUE_TYPE &result,
> > > +const REAL_VALUE_TYPE &op1,
> > > +const REAL_VALUE_TYPE &op2,
> > > +const REAL_VALUE_TYPE &inf)
> > > +{
> > > +  REAL_VALUE_TYPE value;
> > > +  enum machine_mode mode = TYPE_MODE (type);
> > > +  bool mode_composite = MODE_COMPOSITE_P (mode);
> > > +
> > > +  bool inexact = real_arithmetic (&value, code, &op1, &op2);
> > > +  real_convert (&result, mode, &value);
> > > +
> > > +  // If real_convert above has rounded an inexact value to towards
> > > +  // inf, we can keep the result as is, otherwise we'll adjust by 1 ulp
> > > +  // later (real_nextafter).
> > > +  bool rounding = (flag_rounding_math
> > > +&& (real_isneg (&inf)
> > > +? real_less (&result, &value)
> > > +: !real_less (&value, &result)));
> >
> > I thought the agreement during Cauldron was that we'd do this always,
> > regardless of flag_rounding_math.
> > Because excess precision (the fast one like on ia32 or -mfpmath=387 on
> > x86_64), or -frounding-math, or FMA contraction can all increase precision
> > and worst case it all behaves like -frounding-math for the ranges.
> >
> > So, perhaps use:
> >   if ((mode_composite || (real_isneg (&inf) ? real_less (&result, &value)
> > : !real_less (&value, &result))
> >   && (inexact || !real_identical (&result, &value
>
> Done.
>
> > ?
> > No need to do the real_isneg/real_less stuff for mode_composite, then
> > we do it always for inexacts, but otherwise we check if the rounding
> > performed by real.cc has been in the conservative direction (for upper
> > bound to +inf, for lower bound to -inf), if yes, we don't need to do
> > anything, if yes, we frange_nextafter.
> >
> > As discussed, for mode_composite, I think we want to do the extra
> > stuff for inexact denormals and otherwise do the nextafter unconditionally,
> > because our internal mode_composite representation isn't precise enough.
> >
> > > +  // Be extra careful if there may be discrepancies between the
> > > +  // compile and runtime results.
> > > +  if ((rounding || mode_composite)
> > > +  && (inexact || !real_identical (&result, &value)))
> > > +{
> > > +  if (mode_composite)
> > > + {
> > > +   bool denormal = (result.sig[SIGSZ-1] & SIG_MSB) == 0;
> >
> > Use real_isdenormal here?
>
> Done.
>
> > Though, real_iszero needs the same thing.
>
> So... real_isdenormal() || real_iszero() as in the attached patch?
>
> >
> > > +   if (denormal)
> > > + {
> > > +   REAL_VALUE_TYPE tmp;
> >
> > And explain here why is this, that IBM extended denormals have just
> > DFmode precision.
>
> Done.
>
> > Though, now that I think about it, while this is correct for denormals,
> >
> > > +   real_convert (&tmp, DFmode, &value);
> > > +   frange_nextafter (DFmode, tmp, inf);
> > > +   real_convert (&result, mode, &tmp);
> > > + }
> >
> > there are also the cases where the higher double exponent is in the
> > [__DBL_MIN_EXP__, __LDBL_MIN_EXP__] aka [-1021, -968] or so.
> > https://en.wikipedia.org/wiki/Double-precision_floating-point_format
> > If the upper double is denormal in the DFmode sense, so smaller absolute
> > value than __DBL_MIN__, then doing nextafter in DFmode is the right thing to
> > do, the lower double must be always +/- zero.
> > Now, if the result is __DBL_MIN__, the upper double is already normalized
> > but we can add __DBL_DENORM_MIN__ to it, which will make the number have
> > 54-bit precision.
> > If the result is __DBL_MIN__ * 2, we can again add __DBL_DENORM_MIN__
> > and make it 55-bit precision.  Etc. until we reach __DBL_MIN__ * 2e53
> > where it acts like fully normalized 106-bit precision number.
> > I must say I'm not really sure what real_nextafter is doing in those cases,
> > I'm afraid it doesn't handle it correctly but the only other use
> > of real_nextafter is guarded with:
> >   /* Don't handle composite modes, nor decimal, nor modes wi

RE: [PATCH 4/6] Support Intel AVX-NE-CONVERT

2022-10-23 Thread Kong, Lingling via Gcc-patches
> From: Gcc-patches 
> On Behalf Of Hongtao Liu via Gcc-patches
> Sent: Monday, October 17, 2022 1:47 PM
> To: Jiang, Haochen 
> Cc: Liu, Hongtao ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH 4/6] Support Intel AVX-NE-CONVERT
>
> On Fri, Oct 14, 2022 at 3:58 PM Haochen Jiang via Gcc-patches
>  wrote:
> >
> > From: Kong Lingling 
> > +(define_insn "vbcstne2ps_"
> > +  [(set (match_operand:VF1_128_256 0 "register_operand" "=x")
> > +(vec_duplicate:VF1_128_256
> > + (unspec:SF
> > +  [(match_operand:HI 1 "memory_operand" "m")]
> > +  VBCSTNE)))]
> > +  "TARGET_AVXNECONVERT"
> > +  "vbcstne2ps\t{%1, %0|%0, %1}"
> > +  [(set_attr "prefix" "vex")
> > +  (set_attr "mode" "")])
> Since jakub has support bf16 software emulation, can we rewrite it
> with general rtl ir without unspec?
> Like (float_extend:SF (match_operand:BF "memory_operand" "m")
> > +
> > +(define_int_iterator VCVTNEBF16
> > +  [UNSPEC_VCVTNEEBF16SF
> > +   UNSPEC_VCVTNEOBF16SF])
> > +
> > +(define_int_attr vcvtnebf16type
> > +  [(UNSPEC_VCVTNEEBF16SF "ebf16")
> > +   (UNSPEC_VCVTNEOBF16SF "obf16")])
> > +(define_insn "vcvtne2ps_"
> > +  [(set (match_operand:VF1_128_256 0 "register_operand" "=x")
> > +(unspec:VF1_128_256
> > +  [(match_operand: 1 "memory_operand" "m")]
> > + VCVTNEBF16))]
> > +  "TARGET_AVXNECONVERT"
> > +  "vcvtne2ps\t{%1, %0|%0, %1}"
> > +  [(set_attr "prefix" "vex")
> > +   (set_attr "mode" "")])
> Similar for this one and all those patterns below.

That's great! Thanks for the review! 
Now rewrite it without unspec and use float_extend for new define_insn.

Thanks
Lingling




0001-Support-Intel-AVX-NE-CONVERT.patch
Description: 0001-Support-Intel-AVX-NE-CONVERT.patch


Re: [PATCH] d: Remove D-specific version definitions from target headers

2022-10-23 Thread Richard Biener via Gcc-patches
On Sun, 23 Oct 2022, ibuc...@gdcproject.org wrote:

> > On 17/10/2022 20:08 CEST Iain Buclaw  wrote:
> > 
> >  
> > Hi,
> > 
> > This splits up the targetdm sources so that each file only handles one
> > target platform.
> > 
> > Having all logic kept in the headers means that they could become out of
> > sync when a new target is added (loongarch*-*-linux*) or accidentally
> > broken if some headers in tm_file are omitted or changed about.
> > 
> > There might be an open bikeshed question as to appropriate names for
> > some of the platform sources (kfreebsd-d.cc or kfreebsd-gnu-d.cc).
> > 
> > Bootstrapped and regression tested on x86_64-linux-gnu, and also built
> > i686-cygwin, i686-gnu, i686-kfreebsd-gnu, i686-kopensolaris-gnu,
> > x86_64-cygwin, x86_64-w64-mingw32 cross compilers, the dumps of all
> > predefined version identifiers remain correct in all configurations.
> > 
> > OK?
> > 
> 
> Ping?
> 
> I'll apply this tomorrow, but there is a general open question about 
> whether taking logic out of target headers and putting it in config.gcc 
> is the right approach moving forward for non C/C++ front-ends.  This is 
> also relevant for Rust, which initially put all their target support 
> definitions in headers, and have since removed the entire tangled mess 
> that created.

I think Joseph has the best guidance in these areas.  My opinion is
that things that can be done in config.gcc are fine to do there,
especially if it simplifies things or avoids problems in other
places of the compiler.

Richard.


Re: Adding a new thread model to GCC

2022-10-23 Thread i.nixman--- via Gcc-patches

On 2022-10-21 11:44, Eric Botcazou via Libstdc++ wrote:

How does this compare with Eric B's proposal at
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ?


My proposal was to reimplement (and extend) the native thread model 
(win32)
instead of adding a new one, the advantage being that you don't need an 
extra

threading layer between GCC and Windows.


Hello Eric,

could you please refresh/recheck your patch for the current gcc master 
and solve the objections noted in the thread? is it possible?




best!