rnk added a comment.
This seems unfortunately complex, but I think we can live with it for a year or
two.
Is it possible to use the compile time tracker to benchmark if this clang->LLVM
type cache actually saves compile time? This change disables the cache pretty
often, and I'm wondering if "pretty often" is close enough to "all the time" to
let us remove the cache altogether.
---
> Since the LLVM type for z::p can't reference z, Clang simply treats z::p as a
> pointer to an empty struct {}*.
I don't think this is strictly true. LLVM IR struct types can effectively be
forward declared when building IR, using the two-phase
`StructType::create/setBody` APIs. Consider the usual linked list example:
struct z { z *next; };
z head;
-->
%struct.z = type { %struct.z* }
@"?head@@3Uz@@A" = dso_local local_unnamed_addr global %struct.z
zeroinitializer, align 4, !dbg !0
The IR for function prototypes can work similarly, we could produce this IR
struct type:
%struct.z = type { (%struct.z (%struct.z))* }
Maybe that's hard to do today in clang, and ultimately it's probably not worth
investing in generating pretty (function) pointer types given the impending
transition to opaque pointers.
================
Comment at: clang/lib/CodeGen/CodeGenTypes.cpp:34
+#include "llvm/Support/CommandLine.h"
+// TODO: turn on by default when defined(EXPENSIVE_CHECKS) once check-clang is
+// -verify-type-cache clean.
----------------
This cl::opt seems reasonable if we don't expect it to live very long.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D118744/new/
https://reviews.llvm.org/D118744
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
