[PATCH] D118744: [clang] Fix some clang->llvm type cache invalidation issues

[Reid Kleckner via Phabricator via cfe-commits]

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