Chris Lattner wrote:> >> The issue I'm facing is object inheritance and how to find from a LLVM >> type what types it inherits. Currently this can't be implemented in LLVM >> and I need to implement a higher representation for types. >> > > Yep. Sorry :(."Sorry", like "this can really not be integrated in LLVM" or like "it is possible but it requires a lot of work to integrate it"? :)> Depending on your application, you could read debug info, >Actually I am not using llvm-gcc. I'm just targeting a new language and it would have been a lot easier implementing the compiler with LLVM if it had this kind of feature (string <-> type). But if it's not feasible, well I'll just stick with my higher type representation. This leads to another question of type inference for dynamic languages (I refer to your slides from the LLVM meeting day). I do not see how you can integrate type inference on objects in LLVM without knowning inheritance between types. Maybe you only target type inference to dissociate floating point values from integer or object values? Nicolas
On 6/20/07, Nicolas Geoffray <nicolas.geoffray at lip6.fr> wrote:> > Depending on your application, you could read debug info, > > > > Actually I am not using llvm-gcc. I'm just targeting a new language and > it would have been a lot easier implementing the compiler with LLVM if > it had this kind of feature (string <-> type). But if it's not feasible, > well I'll just stick with my higher type representation.Can't this association be established with the new annotation feature? Sandro
On Wed, 20 Jun 2007, Sandro Magi wrote:>> Actually I am not using llvm-gcc. I'm just targeting a new language and >> it would have been a lot easier implementing the compiler with LLVM if >> it had this kind of feature (string <-> type). But if it's not feasible, >> well I'll just stick with my higher type representation. > > Can't this association be established with the new annotation feature?Yes, it probably could. THis would require the programmaer manually annotating things though. The recently added annotation capability is only to be used to propagate source level annotations, not to capture arbitrary information from the front-end. -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Wed, 20 Jun 2007, Nicolas Geoffray wrote:>> Yep. Sorry :(. > > "Sorry", like "this can really not be integrated in LLVM" or like "it is > possible but it requires a lot of work to integrate it"? :)it is not a desired feature for the LLVM type system itself.>> Depending on your application, you could read debug info, >> > > Actually I am not using llvm-gcc. I'm just targeting a new language and > it would have been a lot easier implementing the compiler with LLVM if > it had this kind of feature (string <-> type). But if it's not feasible, > well I'll just stick with my higher type representation.If you control the front-end, you have many options available to you. For example, you could emit your own tables along the same lines as debug info but specialized to capture the metadata you need.> This leads to another question of type inference for dynamic languages > (I refer to your slides from the LLVM meeting day). I do not see how you > can integrate type inference on objects in LLVM without knowning > inheritance between types. Maybe you only target type inference to > dissociate floating point values from integer or object values?I don't propose to do that analysis on the LLVM IR itself. :) -Chris -- http://nondot.org/sabre/ http://llvm.org/
Chris Lattner wrote:> If you control the front-end, you have many options available to you. For > example, you could emit your own tables along the same lines as debug > info but specialized to capture the metadata you need. > >Yes, but this always turns into having two representations for one type: the LLVM representation for its layout, and a personal representation for inheritance. Consider this example from a dynamic language which creates a new list of size four: (define a (new List 4)) If LLVM had type inheritance integrated, all that would be needed is to emit the (new List 4) into LLVM instructions, get the returned type, and set it to the GlobalVariable a. This would simplify a lot of things (for me! :))>> This leads to another question of type inference for dynamic languages >> > > I don't propose to do that analysis on the LLVM IR itself. :) > >Ah, OK. So you propose to do type inference in (all) front-ends? Or maybe on a higher IR? Again, wouldn't it be easier for dynamic language front-end implementations if type inference was just a pass on the LLVM IR? I would surely _love_ to have thins kind of feature :) Nicolas