similar to: [LLVMdev] LLVMC plugin setup changed?

Mikhail Glushenkov wrote: > Hi Sanjiv, > > 2009/6/15 Sanjiv Gupta <sanjiv.gupta at microchip.com>: > >> Hi Mikhail, >> How do you build mcc16 executable? >> > > This should work: > > $ cd $LLVM_DIR/tools/llvmc/examples/mcc16 > $ make > > I configure llvm into a separate directory from source. When I do the steps you mentioned in

Hi Sanjiv, 2009/6/15 Sanjiv Gupta <sanjiv.gupta at microchip.com>: > Hi Mikhail, > How do you build mcc16 executable? This should work: $ cd $LLVM_DIR/tools/llvmc/examples/mcc16 $ make If you're building from some other dir, you'll need to update mcc16/Makefile, so it knows where Makefile.common is located. > There are so many confusing things there: driver, plugins,

Mikhail Glushenkov wrote: > > Hi Sanjiv, > > Sanjiv Gupta <sanjiv.gupta <at> microchip.com> writes: > > > The salient features that we want to have in the driver are: > > [...] > > As promised, I've implemented a basic compiler driver for the > PIC16 toolchain. It's under tools/llvmc/examples/mcc16. > Hi Mikhail, How do you build mcc16

Hello, I use llvm and llvm-gcc as a C-to-C transformation tool using a modified version of the c backend, and rely on llvm debug instructions to link back to the original source code. Does anyone know how to get detailed line number and variable debug information at optimization levels beyond O0? Currently, I extract this debug information by compiling with -g. This works fine with

The programming language mosml comes with foldr that 'accumulates' a function f over a list [x1,x2,...,xn] with initial value b as follows foldr f b [x1,x2,...,xn] = f(x1,...,f(xn-1,f(xn,b))...) Observe that "list" should have same elements so in R terminology it would perhaps be appropriate to say that the accumulation takes place over a 'vector'. I wonder if R

Hi, For my project, I am using internal llvm class functions to print the filename and directory associated with an instruction from the debug information. With a recent checkout of llvm and clang (svn revision 129445), the following custom code (e.g. in a pass that prints directory info for all instructions) returns the filename iso. directory whenever Scope refers to a lexical block: if (const

Hi Devang, >> I use llvm and llvm-gcc as a C-to-C transformation tool using a >> modified version of the c backend, and rely on llvm debug instructions >> to link back to the original source code. >> >> Does anyone know how to get detailed line number and variable debug >> information at optimization levels beyond O0? >> >> Currently, I extract this

Can the driver (llvmc) be built on win32?

Bram Adams wrote: > Hi, > > Op 14-aug-06, om 09:29 heeft Reid Spencer het volgende geschreven: > >> >>> Apparently, %llvmgccdir% and %llvmcc1% are not recognized as a useful >>> variable by the llvmc configuration parser. >> >> >> Actually, they are. See tools/llvmc/ConfigurationDriver.cpp around line >> 304. Also, they are recognized

On Thu, 2006-08-17 at 08:55 -0700, Scott Michel wrote: > Regarding llvmc there is one small problem: with the gcc 4.0 frontend, > "-emit-llvm" needs to be added to all of the translator.command lines. > Not entirely sure how to conditionalize that in the configuration files. Hi Scott, What is needed is a complete overhaul of the configuration mechanism. We have plans to

Reid Spencer wrote: > On Thu, 2006-08-17 at 08:55 -0700, Scott Michel wrote: > >>Regarding llvmc there is one small problem: with the gcc 4.0 frontend, >>"-emit-llvm" needs to be added to all of the translator.command lines. >>Not entirely sure how to conditionalize that in the configuration files. > > > Hi Scott, > > What is needed is a

Hello, guys. I've tried to use llvmc to test optimization options but wasn't successful. Would you mind telling me what's wrong with this? ------------------------------------------------------------- $ llvmc chc_03.c -O3 -o chc_03 terminate called after throwing an instance of 'std::string' llvmc((anonymous namespace)::PrintStackTrace()+0x15)[0x8086091]

Thank you so much for your reply, Chris. If so, can I ask you two things more? First, is there any way to have various optimizations on LLVM assembly such as -O options in llvmc? llvm-gcc doesn't seem to be working for these -O options... Second, I'm still not sure about difference between *.s and *.ll. LLVM assembly *.s file can be made from llvm-gcc with -S option. Another

Hello All, On a Debian/AMD64 host I am surprised that there is apparently no way to generate position independent code in shared object (i.e. to output files which are easy dlopen-able without pain)? I probably missed something obvious, but what? I want to compile LLVM assembly source code -suitably generated- into .so as directly as possible... Regards -- Basile STARYNKEVITCH

On Mon, 22 Oct 2007, Basile STARYNKEVITCH wrote: > On a Debian/AMD64 host I am surprised that there is apparently no way to > generate position independent code in shared object (i.e. to output > files which are easy dlopen-able without pain)? > > I probably missed something obvious, but what? You're missing the fact that llvmc is highly experimental, and is not really usable

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

On Nov 25, 2008, at 9:11 AM, Mikhail Glushenkov wrote: > Hello, > > Since the old llvmc was removed, is it now OK to rename llvmc2 to > llvmc? > I'll update man pages accordingly. yes please! -Chris

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

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

Mikhail Glushenkov wrote: > I removed the '-relocation-model' bit from the default invocation > string for llc. To pass arguments to llc, use the new "-Wllc" > option. I'd say that this is the proper solution, even though it breaks backward compatibility on x86_64. But given that llvmc is still considered experimental, better do it now than later. ;-) Thanks a lot