diff mbox series

dwarf2asm: Use constexpr for eh_data_format_name initialization for C++14

Message ID Zur59Aclxf2wXL3a@tucnak
State New
Headers show
Series dwarf2asm: Use constexpr for eh_data_format_name initialization for C++14 | expand

Commit Message

Jakub Jelinek Sept. 18, 2024, 4:04 p.m. UTC 
Hi!

Similarly to the previous patch, dwarf2asm.cc had
HAVE_DESIGNATED_INITIALIZERS support, and as fallback a huge switch.
The switch from what I can see is expanded as a jump table with 256
label pointers and code at those labels then loads addresses of
string literals.
The following patch instead uses a table with 256 const char * pointers,
NULL for ICE, non-NULL for returning something, similarly to the
HAVE_DESIGNATED_INITIALIZERS case.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2024-09-18  Jakub Jelinek  <jakub@redhat.com>

	* dwarf2asm.cc (eh_data_format_name): Use constexpr initialization
	of format_names table for C++14 instead of a large switch.


	Jakub

Comments

Jeff Law Sept. 18, 2024, 4:51 p.m. UTC | #1 
On 9/18/24 10:04 AM, Jakub Jelinek wrote:
> Hi!
> 
> Similarly to the previous patch, dwarf2asm.cc had
> HAVE_DESIGNATED_INITIALIZERS support, and as fallback a huge switch.
> The switch from what I can see is expanded as a jump table with 256
> label pointers and code at those labels then loads addresses of
> string literals.
> The following patch instead uses a table with 256 const char * pointers,
> NULL for ICE, non-NULL for returning something, similarly to the
> HAVE_DESIGNATED_INITIALIZERS case.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2024-09-18  Jakub Jelinek  <jakub@redhat.com>
> 
> 	* dwarf2asm.cc (eh_data_format_name): Use constexpr initialization
> 	of format_names table for C++14 instead of a large switch.
Do we want to defer this while the discussion around moving to c++14 
plays out?  Or would you prefer to move forward and if we move to c++14 
come back and simplify?

Jeff
Jakub Jelinek Sept. 18, 2024, 5 p.m. UTC | #2 
On Wed, Sep 18, 2024 at 10:51:49AM -0600, Jeff Law wrote:
> On 9/18/24 10:04 AM, Jakub Jelinek wrote:
> > Hi!
> > 
> > Similarly to the previous patch, dwarf2asm.cc had
> > HAVE_DESIGNATED_INITIALIZERS support, and as fallback a huge switch.
> > The switch from what I can see is expanded as a jump table with 256
> > label pointers and code at those labels then loads addresses of
> > string literals.
> > The following patch instead uses a table with 256 const char * pointers,
> > NULL for ICE, non-NULL for returning something, similarly to the
> > HAVE_DESIGNATED_INITIALIZERS case.
> > 
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > 
> > 2024-09-18  Jakub Jelinek  <jakub@redhat.com>
> > 
> > 	* dwarf2asm.cc (eh_data_format_name): Use constexpr initialization
> > 	of format_names table for C++14 instead of a large switch.
> Do we want to defer this while the discussion around moving to c++14 plays
> out?  Or would you prefer to move forward and if we move to c++14 come back
> and simplify?

I'm fine either way.
Note, the #if HAVE_DESIGNATED_INITIALIZERS parts could be removed too now
that we compile the stuff with C++ (for years).  clang++ actually does
support int a[3] = { [2] = 1, [0] = 2 }; but warns about it by default.

	Jakub
Jeff Law Sept. 18, 2024, 11:30 p.m. UTC | #3 
On 9/18/24 11:00 AM, Jakub Jelinek wrote:
> On Wed, Sep 18, 2024 at 10:51:49AM -0600, Jeff Law wrote:
>> On 9/18/24 10:04 AM, Jakub Jelinek wrote:
>>> Hi!
>>>
>>> Similarly to the previous patch, dwarf2asm.cc had
>>> HAVE_DESIGNATED_INITIALIZERS support, and as fallback a huge switch.
>>> The switch from what I can see is expanded as a jump table with 256
>>> label pointers and code at those labels then loads addresses of
>>> string literals.
>>> The following patch instead uses a table with 256 const char * pointers,
>>> NULL for ICE, non-NULL for returning something, similarly to the
>>> HAVE_DESIGNATED_INITIALIZERS case.
>>>
>>> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>>>
>>> 2024-09-18  Jakub Jelinek  <jakub@redhat.com>
>>>
>>> 	* dwarf2asm.cc (eh_data_format_name): Use constexpr initialization
>>> 	of format_names table for C++14 instead of a large switch.
>> Do we want to defer this while the discussion around moving to c++14 plays
>> out?  Or would you prefer to move forward and if we move to c++14 come back
>> and simplify?
> 
> I'm fine either way.
> Note, the #if HAVE_DESIGNATED_INITIALIZERS parts could be removed too now
> that we compile the stuff with C++ (for years).  clang++ actually does
> support int a[3] = { [2] = 1, [0] = 2 }; but warns about it by default.
Then it's your call.  I'm fine with the patch as-is  or with waiting for 
the simplifications enabled by C++14.

jeff
diff mbox series

Patch

--- gcc/dwarf2asm.cc.jj	2024-01-03 11:51:28.611771716 +0100
+++ gcc/dwarf2asm.cc	2024-09-18 10:12:30.916464439 +0200
@@ -488,14 +488,22 @@  eh_data_format_name (int format)
 {
 #if HAVE_DESIGNATED_INITIALIZERS
 #define S(p, v)		[p] = v,
+#elif __cpp_constexpr >= 201304L
+#define S(p, v)		names[p] = v;
 #else
 #define S(p, v)		case p: return v;
 #endif
 
 #if HAVE_DESIGNATED_INITIALIZERS
   __extension__ static const char * const format_names[256] = {
+#elif __cpp_constexpr >= 201304L
+  static constexpr struct format_names_s {
+    const char *names[256];
+    constexpr format_names_s () : names {}
+    {
 #else
-  switch (format) {
+  switch (format)
+    {
 #endif
 
   S(DW_EH_PE_absptr, "absolute")
@@ -635,8 +643,15 @@  eh_data_format_name (int format)
   gcc_assert (format >= 0 && format < 0x100 && format_names[format]);
 
   return format_names[format];
+#elif __cpp_constexpr >= 201304L
+    }
+  } format_names;
+
+  gcc_assert (format >= 0 && format < 0x100 && format_names.names[format]);
+
+  return format_names.names[format];
 #else
-  }
+    }
   gcc_unreachable ();
 #endif
 }