llvm dev - Apr 2008 - [LLVMdev] PHP Zend LLVM extension (SoC)

On Apr 23, 2008, at 10:49 PM, Owen Anderson wrote:
>
> On Apr 23, 2008, at 1:44 PM, Nuno Lopes wrote:
>
>> Thank you both for your answers!
>> That part of type inference was my second question. PHP uses a  
>> structure
>> with a union to represent a variable (because a variable can have  
>> different
>> types, like a long, a double, a stream, etc..), but often a single  
>> variable
>> will only have one type throughout the program (e.g. iterating  
>> through $i in
>> a loop). Will LLVM automagically see that we always use the same  
>> type for a
>> certain variable and discard the whole union and use a single  
>> scalar (and
>> also discard all the type checking done in the opcode handlers)? We  
>> can do
>> some type inference on our side if we do a pass on the bytecode,  
>> but I would
>> like to be sure if that's needed or if LLVM will do it on its own.
>>
>
> LLVM likely won't be able to do type inference for you.
I'd put it another way: an existing llvm pass won't do type inference  
for you.  The right way to tackle this is to write an language- 
specific pass on LLVM IR that knows your runtime and can propagate  
types around.

-Chris

On Apr 24, 2008, at 12:54 AM, Chris Lattner wrote:
>> LLVM likely won't be able to do type inference for you.
>
> I'd put it another way: an existing llvm pass won't do type
inference
> for you.  The right way to tackle this is to write an language-
> specific pass on LLVM IR that knows your runtime and can propagate
> types around.
>
Or just do it at the Zend bytecode level.

The meta-point is that performing that kind of optimization requires  
higher level knowledge than what is explicitly represented in the LLVM  
IR.  To obtain it, you either need to optimize at a higher level or  
write an LLVM optimization that encodes language-specific high-level  
knowledge.  Either approach will work, and it's your call which one is  
easier for you to write.

--Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4260 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080424/06b7b4ed/attachment.bin>

Owen, Chris,

Owen Anderson wrote:
>
> On Apr 24, 2008, at 12:54 AM, Chris Lattner wrote:
>>> LLVM likely won't be able to do type inference for you.
>>
>> I'd put it another way: an existing llvm pass won't do type
inference
>> for you.  The right way to tackle this is to write an language-
>> specific pass on LLVM IR that knows your runtime and can propagate
>> types around.
The thing is, LLVM IR performs type checking when it's being constructed 
(e.g BinaryOperator::CreateAdd(A, B) checks A->type == B->type or 
BinaryOperator::CreateFDiv(A,B) checks if A is floating point, B is 
floating point and A->type == B->type). That's a stopper for
performing
type inference on the LLVM IR.  To perform type inference on the IR, one 
should add/modify:

1) Setting the arguments of a function as Opaque (or something like 
that, at least something that is able to be redefined later)
2) IR construction: no type check, no type-oriented instructions (eg no 
CreateFDiv)
3) Add some meta-information on each instruction (is that the Annotation 
thing?)
4) Perform the type inference.
5) Perform type checking.
>
> Or just do it at the Zend bytecode level.
I think that's currently the only solution. However:

A) Suppose you don't have a bytecode for your language or you would like 
to directly transform your language to LLVM IR. You don't want to end up 
creating an instruction set which would be very similar to LLVM IR. 
That's highly time and memory consuming since you're creating new 
objects for your personal instruction set, very similar to LLVM IR 
objects. (I may be thinking too much about JIT here, since it's less a 
problem with static compilation).

B) This is the kind of pass that many languages will need, and everyone 
performing its own is not very consistent with LLVM philosophy ;-)

I'm not saying 1) to 5) are the right steps to achieve this. But I do 
think we need the LLVM IR to get some high-level type information for 
type inference or even for type-based optimizations such as type-based 
alias-analysis.


Nicolas
>
> The meta-point is that performing that kind of optimization requires 
> higher level knowledge than what is explicitly represented in the LLVM 
> IR.  To obtain it, you either need to optimize at a higher level or 
> write an LLVM optimization that encodes language-specific high-level 
> knowledge.  Either approach will work, and it's your call which one is 
> easier for you to write.
>
> --Owen
> ------------------------------------------------------------------------
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>