dwarf2asm: Use constexpr for eh_data_format_name initialization for C++14
Checks
| Context |
Check |
Description |
| linaro-tcwg-bot/tcwg_gcc_build--master-aarch64 |
success
|
Build passed
|
| linaro-tcwg-bot/tcwg_gcc_check--master-aarch64 |
success
|
Test passed
|
| linaro-tcwg-bot/tcwg_gcc_build--master-arm |
success
|
Build passed
|
| linaro-tcwg-bot/tcwg_gcc_check--master-arm |
success
|
Test passed
|
Commit Message
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
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
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
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
@@ -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
}