search for: codedgers

Hello, Everyone. We've just commited new backend for LLVM: MSIL. The author of backend is Roman Samoilov from Codedgers Inc. (roman at codedgers.com). Backend itself is very similar to C backend (and actually was based on it). Note, it's pure LLVM-to-MSIL translator, so no additional checks etc. are performed. Backend is usable in general, but still lacks some important features: 1. There is no way to tell &qu...

WikiFormatting for code documentation? :-) -scooter On Tue, Dec 9, 2008 at 7:56 AM, Mikhail Glushenkov <foldr at codedgers.com>wrote: > [Chris asked me to bring this up on the mailing list some time > ago, but I couldn't get to it. Sorry for that.] > > Since the beginning, I used ReST [1] for documenting llvmc, instead of > plain HTML that was used historically. In my opinion, ReST is much > e...

And the followup: http://lhc-compiler.blogspot.com/2009/01/why-llvm-probably-wont-replace-c.html On Sat, Jan 17, 2009 at 1:18 PM, Mikhail Glushenkov <foldr at codedgers.com> wrote: > > This may be of interest: > > http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html > > People implementing a new Haskell compiler explain why LLVM is an > unsuitable target for them. > > _______________________________________________ > LL...

Anton Korobeynikov wrote: > Hello, Everyone. > > We've just commited new backend for LLVM: MSIL. The author of backend is > Roman Samoilov from Codedgers Inc. (roman at codedgers.com). Backend itself > is very similar to C backend (and actually was based on it). Note, it's > pure LLVM-to-MSIL translator, so no additional checks etc. are > performed. > I'm confused. A MSIL front end I can understand, but a back end? How wil...

This may be of interest: http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html People implementing a new Haskell compiler explain why LLVM is an unsuitable target for them.

[Chris asked me to bring this up on the mailing list some time ago, but I couldn't get to it. Sorry for that.] Since the beginning, I used ReST [1] for documenting llvmc, instead of plain HTML that was used historically. In my opinion, ReST is much easier to write and read (in the text editor or on terminal); it can also be used to produce PDFs, man pages or HTML that looks exactly the same

It's nice that he claims it's way too high overhead without any, you know, data. Then again, he also thinks writing a good native code generator isn't that difficult, so .... On Sat, Jan 17, 2009 at 1:18 PM, Mikhail Glushenkov <foldr at codedgers.com> wrote: > This may be of interest: > > http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html > > People implementing a new Haskell compiler explain why LLVM is an > unsuitable target for them. > > _______________________________________________ > LLVM De...

Hi Mikhail, > Aaron Gray <aaronngray.lists <at> googlemail.com> writes: >> I have not tried as of yet. > > Just compile with `make VERBOSE=1` and then copy, paste & edit > the offending line. Okay >> I don't think Cygwin supports loadable modules anyway. > > Really, Cygwin doesn't allow to produce DLLs? Then I guess I > should make this a

Hi Aaron, Aaron Gray <aaronngray.lists <at> googlemail.com> writes: > I sent you a _patch_ that disables it on Cygwin for the time being. LLVM > does not load DLL's properly apparently. I would love to get to the bottom > of this at some point. I've just added an --enable-llvmc-dynamic configure option (enabled only on Windows by default). This is based on your

Hi Daniel, Daniel Dunbar <daniel <at> zuster.org> writes: > > Ultimately I think a better API would be to provide a generic class > which represents an executed operating system process, and includes > operations to wait for its completion, redirect its IO, communicate > with it, etc. This would be a big improvement over the current > monolithic function. I agree,

On Thu, Jul 16, 2009 at 7:48 PM, Mikhail Glushenkov<foldr at codedgers.com> wrote: > Hi Daniel, > > Daniel Dunbar <daniel <at> zuster.org> writes: > >> >> Ultimately I think a better API would be to provide a generic class >> which represents an executed operating system process, and includes >> operations to wait for...

Hi, I am trying to build my own llvmc plugin, but somehow, the llvm makefiles do not pick up the plugin in the llvmc/plugins directory anymore in a recent (r129445) svn checkout. According to the tutorial (http://llvm.org/docs/CompilerDriverTutorial.html): $ cd tools/llvmc $ cp -r example/Simple plugins/Simple $ make LLVMC_BASED_DRIVER_NAME=mygcc LLVMC_BUILTIN_PLUGINS=Simple does not build

Hello, Holger > Being fully aware that llvmc2 is work-in-progress, here are some notes nethertheless: First of all - Mikhael (the main author) sometimes cannot catch the mailing list directly, so please, CC him also (foldr at codedgers.com) I'll try to answer some questions and Mikhael will try to resolve others. > * why using /tmp at all? Same does gcc, we don't have pipe option yet. > And if, why /tmp/llvm_* and not /tmp/llvmc2_* ? Well, llvm_ - because we're using general LLVM routines for generation of t...

...tion. That said, designing and implementing that is more work. However, I'd rather either see that done, or clients do their own process stuff, than have the llvm::sys API expose operating system dependent information. - Daniel On Thu, Jul 16, 2009 at 6:04 PM, Mikhail Glushenkov<foldr at codedgers.com> wrote: > --- >  include/llvm/System/Program.h |   14 ++++++++++---- >  lib/System/Unix/Program.inc   |   17 +++++++++-------- >  lib/System/Win32/Program.inc  |   16 +++++++++------- >  3 files changed, 28 insertions(+), 19 deletions(-) > > diff --git a/include/llvm/Sys...

--- include/llvm/System/Program.h | 8 ++++---- lib/System/Unix/Program.inc | 30 +++++++++++++++--------------- 2 files changed, 19 insertions(+), 19 deletions(-) diff --git a/include/llvm/System/Program.h b/include/llvm/System/Program.h index 49de7cf..14f9e9e 100644 --- a/include/llvm/System/Program.h +++ b/include/llvm/System/Program.h @@ -97,12 +97,12 @@ namespace sys { ///

--- include/llvm/System/Program.h | 14 ++++++++++---- lib/System/Unix/Program.inc | 17 +++++++++-------- lib/System/Win32/Program.inc | 16 +++++++++------- 3 files changed, 28 insertions(+), 19 deletions(-) diff --git a/include/llvm/System/Program.h b/include/llvm/System/Program.h index 14f9e9e..05c73ac 100644 --- a/include/llvm/System/Program.h +++ b/include/llvm/System/Program.h @@

Hello, Since the old llvmc was removed, is it now OK to rename llvmc2 to llvmc? I'll update man pages accordingly.

Greetings everybody! In my quest to attract more users to llvmc, I've added support for compilation via the Clang front-end (previously, only llvm-gcc was supported). This is enabled with the '-clang' switch; basically, you can now just alias 'ccc' to 'llvmc -clang' and get the same functionality. Examples: Compile via Clang: $ llvmc -clang test.c

> Can you compare ReST to docbook? We've talked about using docbook for > a long time. What are the pros and cons of each? I have no experience with DocBook, but it seems that since it is XML-based it should also suffer from verbosity issues. For example, the Boost project, which originally used plain DocBook, decided to build a new ReST-like documentation format[1] on top of it. [1]

Hi, > According to the FAQ llvmc is considered experimental/unsupported. But > FWIW, here's an issue I found while trying to use it on 32 bit x86 systems. I am the primary maintainer of llvmc. First of all, thanks for your bug report. > tools/llvmc/plugins/Base/Base.td hardcodes the -relocation-model=pic > option into invocations of llc: This part was copied verbatim from the