Bug 91937 - _Generic Feature Expansion
Summary: _Generic Feature Expansion
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 9.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2019-09-30 15:14 UTC by Srinath Parvathaneni
Modified: 2019-10-01 07:21 UTC (History)
1 user (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed:

Preprocessor output (577 bytes, text/plain)
2019-09-30 15:14 UTC, Srinath Parvathaneni

Note You need to log in before you can comment on or make changes to this bug.
Description Srinath Parvathaneni 2019-09-30 15:14:44 UTC
Created attachment 46983 [details]
Preprocessor output

On compiling the following test.c with gcc and checking the preprocessor file.

In C, for a macro using "_Generic" feature, "_Generic" expands completely but not just for the matching case. This expansion is increasing the pre-processor file size enormously in case of nested macros and slowing down the compiler.

$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.11' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.11) 

$ cat test.c
enum {
  type_int_t = 1,

float bb;
char cc;

#define _TYPE(x) _Generic(x, \
    int *: type_int_p_t, \
    float *: type_float_p_t, \
    char *:  type_char_p_t, \
    default: _Generic(x, \
        short: type_int_16, \
        long: type_int_32,\
	int: type_int_t, \
        char: type_char_t, \
        float: type_float_t))

extern void *__undef;
#define cast(param, type) \
    _Generic(param, type: param, default: *(type *)__undef)

#define reg(p0) _Generic( \
   (int (*)[_TYPE(p0)])0, \
  int (*)[type_int_t]: reg_s8(cast(p0, int)), \
  int (*)[type_char_t]: reg_f8(cast(p0, char)), \
  int (*)[type_float_t]: reg_c8(cast(p0, float)), \
  int (*)[type_int_p_t]: reg_sp(cast(p0, int *)), \
  int (*)[type_float_p_t]: reg_fp(cast(p0, float *)), \
  int (*)[type_char_p_t]: reg_cp(cast(p0, char *)))

reg_s8(int a)
  return bb;

void reg_f8(float a){}
void reg_c8(char a){}
void reg_sp(int *a){}
void reg_fp(float *a){}
void reg_cp(char *a){}

int main()
  int a;
  float b;
  char c;
  reg(reg(a)); // more levels of nesting, more complex preprocessor output.
  return 0;

$ gcc test.c --save-temps
Comment 1 Jakub Jelinek 2019-09-30 16:23:24 UTC
It is unclear what you are complaining about, for the preprocessor, _Generic is a token like any other, it is up to the user to use preprocessor in a sane way to avoid creating too large output, just watch p0 being used in reg macro 7 times and x in _TYPE macro twice, so you can easily do the math.
Comment 2 Srinath Parvathaneni 2019-09-30 16:48:16 UTC
I'm using _Generic to create polymorphic implementations of MVE intrinsics.
MVE have more than 50 data types (combinations) and intrinsics with more upto 5 arguments. So on nesting a call to just two intrinsics is expanding to more than 4000 lines. The nesting of calls increases pre-processor output exponentially and slowing down the compiler.

I'm expecting "_Generic" could expand only to exactly matching combination which would optimize the pre-processor output file size.
Comment 3 Jakub Jelinek 2019-09-30 16:55:13 UTC
Then perhaps you want to use C++ instead of C?
The way the preprocessor works and the way _Generic works is defined in the C standard, we can't handle it just differently from what the standard says, and the type decisions for _Generic can't be done during preprocessing, because that requires syntactic analysis of the source.
E.g. glibc tgmath.h implementation using _Generic was suffering similarly and lead into the introduction of compiler builtin that handles what tgmath.h needs.
Comment 4 Richard Biener 2019-10-01 07:21:19 UTC