[LLVMdev] Extending LLVM for high-level types

[Alexandre Cossette]

On 2011-01-13, at 7:54 PM, Andrew Clinton wrote:
> On 01/13/2011 03:46 AM, Nick Lewycky wrote:
>> In short, LLVM is its own language. You don't need to extend LLVM IR to
>> support your programming language any more than you need to extend x86
>> processors to support it.
> 
> I think that what Alexandre wants to do is to leverage the power of the 
> LLVM SSA transformation/optimization framework for types that might not 
> be natively defined by LLVM.
Yes, exactly!

> This is something that I believe is 
> already possible in LLVM (with the addition of some select user-defined 
> passes and careful use of types), but it can be awkward to use due to 
> the structure typing inherent in LLVM.  For example, I define one of the 
> custom types in my language to i64, but this only makes sense as long as 
> I can uniquely identify this type as i64 - that is I haven't overloaded 
> i64 to mean anything else.  Other types could be introduced as other 
> bit-width integers (i65), structure types, etc.  So it's possible, if 
> not clean.
Isn't it dangerous to use integer types like this? Optimization passes might introduce bitcasts or other instructions that assume integer semantics.

> Actually, looking over the list of optimizations on LLVM IR I'm having 
> trouble finding more than a handful that explicitly rely on the storage 
> type of all data.  So it seems like a very valid use case to use LLVM 
> for optimization with user-specific types within SSA form, before 
> lowering the code (or translating back to source).
I have a hard time making sure it's the case by just reading the passes source code. LLVM often assumes that its set of types is fixed and takes shortcuts.

Alex