Introduce a simplified C IR.

[phadej]

When working with data declarations recently, I stumble all the time on "complexity" of C. For example

#include <stdio.h>

typedef struct foo_s {
	int x;
} foo_t;

int main() {
	struct foo_s y = {0};

	return 0;
}

works. There typedef declaration is two-in-one:

struct foo_s {
  int x;
};

typedef struct foo_s foo_t;

For humans the two-in-one notion maybe handy; but for code-processing having simpler blocks is... simpler.

---

So I suggest that we introduce a simplified C IR, elaborating some compound C declarations into simpler ones.

---

To continue an example, I'd argue that even

typedef struct {
  int x; int y;
} foo;

is easier to process as (in pseudo-C)

struct anonymous::typedef<foo> {
  int x; int y;
} 

typedef anonymous::typedef<foo> foo;

and similar transformations may applied to "flatten" nested structs and unions.

[TravisCardwell]

Normalizing data declarations sounds good. For name mangling, we need to make sure that the IR has the necessary context. For example, the context for an anonymous struct for a named field currently needs to have the Haskell type constructor name of the closest named ancestor and the C field name. If providing Haskell names is problematic with IR, we can instead provide the context required to create the Haskell name. In this example, just the C name that is mangled to the type constructor name is sufficient.

Example:

typedef struct rect {
  struct { int x; int y; } tl;
  struct { int x; int y; } br;
} rect;

IR sketch:

struct ir::anonymous<rect, tl> {
  int x;
  int y;
};

struct ir::anonymous<rect, br> {
  int x;
  int y;
};

struct ir::struct<rect> {
  struct ir::anonymous<rect, tl> tl;
  struct ir::anonymous<rect, br> br;
};

typedef ir::struct<rect> rect;

Haskell with default options

data CRectTl = MkCRectTl {
      cRectTlX :: Int
    , cRectTlY :: Int
    }

data CRectBr = MkCRectBr {
      cRectBrX :: Int
    , cRectBrY :: Int
    }

data CRect = MkCRect {
      cRectTl :: CRectTl
    , cRectBr :: CRectBr
    }

By the way, I am about to implement a change to name mangling that should make it easier to use due to improved organization and documentation.

[edsko]

Yes, this sounds completely reasonable to me. I wonder if we can the AST annotations (#256) to provide some additional guarantees which kinds of simplications have taken place?

[phadej]

some additional guarantees

Why?

[edsko]

So that subsequent passes can depend on it....?

[phadej]

So that subsequent passes can depend on it....?

I assume you meant that we'd use same types for input C and simplified IR. I'm against that. They are different enough that having separate structures is a lot cleaner, than trying to be clever how to not duplicate stuff.

[edsko]

Oh, I see.

[phadej]

Kind of done in #295