[PATCH] D49403: More aggressively complete RecordTypes with Function Pointers

[Andy Kaylor via Phabricator via cfe-commits]

andrew.w.kaylor added a comment.

I've talked to Olga about this, and I think we have a way to handle the problem she was working on without this change.

However,  I think this change is worth considering anyway. The test case shows an example where clang is clearly not producing the output it intends to produce. In most cases that probably doesn't matter, and I can't come up with any case where it will result in incorrect code generation. One place that I think it has the potential to introduce trouble is with LTO.

Modifying the example from the test case slightly, suppose you have that code broken up into two source files like this.

f1.c:

  struct has_fp;
  typedef void (*fp)(const struct has_fp *f);
  struct has_fp {
    fp i;
  };
  void func(const struct has_fp *f) {}

f2.c:

  struct has_fp;
  typedef void (*fp)(const struct has_fp *f);
  struct has_fp {
    fp i;
  };
  void func(const struct has_fp *f);
  void func2(const struct has_fp *f, int n) {
    if (n == 0)
      func(f);
  }

Now if I compile both of these files with "-c -flto -O2" and then use "llvm-link -S -o - f1.o f2.o" I'll see the following:

  %struct.has_fp = type { {}* }
  %struct.has_fp.0 = type { void (%struct.has_fp.0*)* }
  
  define void @func(%struct.has_fp* %f) {
  entry:
    ret void
  }
  
  define void @func2(%struct.has_fp.0* %f, i32 %i) {
  entry:
    %cmp = icmp eq i32 %i, 0
    br i1 %cmp, label %if.end, label %if.then
  
  if.then:
    tail call void bitcast (void (%struct.has_fp*)* @func to void (%struct.has_fp.0*)*)(%struct.has_fp.0* %f)
    br label %if.end
  
  if.end:
    ret void
  }

Granted, this will ultimately produce correct code, and I don't have an example handy that shows how the extra type and the function bitcast might inhibit optimizations, but I think we're at least a step closer to being able to imagine it.


https://reviews.llvm.org/D49403