[LLVMdev] Advice on CFG pre-analysis

[Chris Lattner]

On May 23, 2008, at 11:53 PM, Talin wrote:
> In the language I am working on, there are cases where the call flow
> graph can affect the type of a variable.

Ok.

> A simple example is a
> "nullable" type (a pointer which is allowed to be NULL), which can be
> converted into a non-nullable type via an if-test. So for example if x
> is nullable, and I test x != NULL, then inside the conditional block  
> the
> type of x is no longer nullable.

Makes sense.

> Nullable types behave slightly
> differently (and produce less efficient code) than non-nullable types.
> For example, a downcast to a nullable type is a dynamic cast  
> (because if
> the cast fails, the result can be NULL), whereas a downcast to a
> non-nullable type throws an exception if the cast fails.

Sure.

> This kind of analysis is trivial given LLVM's architecture. The  
> problem
> I have, however, is that all of the high-level type analysis occurs
> before LLVM ever gets into the picture. LLVM doesn't know anything  
> about
> the front-end type system.

Why not codegen this logically as a pair of <bool, T> where each is an  
LLVM Value*?  This would allow the optimizer to propagate around and  
eliminate the bool.

> What I am wondering is, will I have to re-invent the same sort of CFG
> analysis that LLVM does in my frontend, or is there some shortcut? I
> guess this is really a general compiler-design question rather than  
> one
> specific to LLVM, but I thought I would ask anyway.

This issue is fairly straight-forward I think.  More general problems  
are things like auto-unboxing of types and doing type inference of  
source level languages.  This can also be done pretty easily in the  
LLVM IR, if you have questions about that I can explain.

-Chris