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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
