C2 forum

General Category => Ideas => Topic started by: lerno on November 05, 2018, 06:35:38 PM

Title: Does C2 support this? Otherwise it should. "Labels as values"
Post by: lerno on November 05, 2018, 06:35:38 PM

For some problem domains, this can be extremely effective:

https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

Title: Re: Does C2 support this? Otherwise it should. "Labels as values"
Post by: bas on November 09, 2018, 08:39:12 PM

Wow, I never even knew that was possible in C. I have also never ever found the need for it as well ;)
I think this can safely be removed.

Title: Re: Does C2 support this? Otherwise it should. "Labels as values"
Post by: lerno on November 09, 2018, 09:32:18 PM

I can be used to create extremely fast "jump tables" for switches. Actually, identifying keywords is a very good usecase for it. Of course, many compilers already implement switches as jump tables. This is a way to do what otherwise would need a function call.

Consider:

Code: [Select]

int foo(int x) { return x + x; }
int bar(int x) { return x * x; }
int baz(int x) { return x * x + x; }

static inline int dispatch_on_type(enum Foobar foobar, int x) {
  static int (*foobars[3])(int) = { foo, bar, baz };
  return foobars[foobar](x);
}

This code requires loads and function calls. Compare this to using labels:

Code: [Select]

int foo(int x) { ... }
int bar(int x) { ... }
int baz(int x) { ... }

static inline int dispatch_on_type(enum Foobar foobar, int x) {
  static void **foobars[3] = { &&foo, &&bar, &&baz };
  goto *foobars[foobar];
  foo:
  return x + x;
  bar:
  return x * x;
  baz:
  return x * x + x;
}

It's easy to recognize this as what the compiler already does when optimizing a switch. The point is that this adds additional flexibility that isn't possible in a plain switch. I like it but not priority 1.

Title: Re: Does C2 support this? Otherwise it should. "Labels as values"
Post by: bas on November 13, 2018, 08:43:48 AM

Indeed, It could be used for some corner cases. Let's put it on the backlog somewhere