search for: giuca

OK thanks for the replies. Yes, I was planning to use a garbage collector. This is for a functional language, so there's no real way to determine when memory needs to be freed without one. > Firstly, the pointer has to not make it into any function call at all, since any function might in turn call free(). Then we need to do escape analysis as you pointed out, but that's not

I have a compiler which generates a lot of malloc instructions for basically all data. I was rather hoping that these mallocs would be converted to allocas if the pointers didn't escape. This would require an escape analysis, and I'm not sure if LLVM has such a thing. For instance, consider this code (typical of the output of my compiler): define i32 @dontescape(i32 %x) { entry:   %t =

Alastair Lynn wrote: > > From what I understand, the unwind instruction is implemented only > for the interpreter: there is a -lowerunwind pass for compiling to > other systems which will either lower unwind and invoke to setjmp/ > longjmp (slow) or turn invokes into calls and unwinds into abort()s. > Ah cheers, Alastair. That could be very useful (at least for me

...at I understand, the unwind instruction is implemented only for the interpreter: there is a -lowerunwind pass for compiling to other systems which will either lower unwind and invoke to setjmp/ longjmp (slow) or turn invokes into calls and unwinds into abort()s. On 26 Dec 2008, at 15:19, Matt Giuca wrote: > > > Jon Harrop wrote: >> >> Is it? I was just reading the documentation about LLVM's exception >> handling >> and it sounded ideal for my needs. How much of it does not work as >> the >> docs >> imply? >> > > Jon, I ran...

Jon Harrop wrote: > > Is it? I was just reading the documentation about LLVM's exception > handling > and it sounded ideal for my needs. How much of it does not work as the > docs > imply? > Jon, I ran into this issue in September and re-ignited this discussion in another thread, here: http://www.nabble.com/Unwinds-Gone-Wild-td18747589.html

On Mon, Sep 29, 2008 at 8:49 PM, Matt Giuca <mattgiuca at gmail.com> wrote: > /* snip */ The language I am making is not a traditional scripting language, it is designed for heavy math work. It has not classes, the basic data structure is a struct, yet even those are only used to pass messages. It is using the Actor-Oriented model...

Matt Giuca wrote: > OK thanks for the replies. > > Yes, I was planning to use a garbage collector. This is for a > functional language, so there's no real way to determine when memory > needs to be freed without one. > >> Firstly, the pointer has to not make it into any function ca...

...ave any such optimization. Firstly, the pointer has to not make it into any function call at all, since any function might in turn call free(). Then we need to do escape analysis as you pointed out, but that's not difficult. We do similar analysis to determine pointer capture already. Matt Giuca wrote: > I have a compiler which generates a lot of malloc instructions for > basically all data. I was rather hoping that these mallocs would be > converted to allocas if the pointers didn't escape. This would require > an escape analysis, and I'm not sure if LLVM has such a th...

OvermindDL1 wrote: > > I know why it was removed, and it does make sense, just would be nice > if there was an option to be able to get two pointer to a specific > llvm::IntegerType, functionally they would be identical, but for user > code (hence, my code) would be useful as I could match it for the > different ones at generate different code for each. > Well a language

On Mon, Sep 29, 2008 at 9:48 PM, Matt Giuca <mattgiuca at gmail.com> wrote: > It seems like your language is very high level indeed (it almost sounds > dynamic). If you can pass arbitrary messages without needing to statically > know the type of anything, and pass data transparently from one machine to > another. It is in n...

OvermindDL1 wrote: > > It is using the Actor-Oriented model, not Object-Oriented. > /* snip */ > By keeping the type system based on the actual types it allows > arbitrary message passing to any other actor without needing to load > any code relating to the actors, you can just send a structure with > the appropriate ID and format and it will 'just work' as the

Duncan Sands wrote: > > since libgcc is available everywhere llvm is, it's as multi-platform > as llvm! If we didn't use libgcc then we'd have to introduce an llvm > runtime library. Since it would just duplicate the functionality of > libgcc, it would introduce an additional maintenance burden without > bringing any real advantage AFAICS. > So if there's

Marc de Kruijf wrote: > > Can anyone tell me if invoke/unwind is stable in 2.3? I'm seeing some > really weird stuff -- unwinds are ending up in seemingly arbitrary > places... > definitely not inside the caller's unwind block My target is x86. > > As a simple test, I tried to compile the following code and I got a > segmentation fault. It looks good to me.