similar to: [LLVMdev] Passing arguments to opt via clang

Thanks, but I'm not sure I understand. I see no such flag in clang 2.9 nor couldn't I find any mention of it. What does it do? Harel Cain On Sun, Mar 4, 2012 at 15:03, Anton Korobeynikov <anton at korobeynikov.info>wrote: > > In the good old llvmc, the -Wo flag could be used to pass arguments to > the > > optimizer. Is there a similar mechanism anywhere for clang?

> In the good old llvmc, the -Wo flag could be used to pass arguments to the > optimizer. Is there a similar mechanism anywhere for clang? Is there also a > similar mechanism to -Wllc? -mlvm will handle all of them -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On 03/04/2012 02:32 PM, Harel Cain wrote: > Thanks, but I'm not sure I understand. I see no such flag in clang 2.9 > nor couldn't I find any mention of it. What does it do? It's called -mllvm. You can use it like this. clang -mllvm -vectorize ... Cheers Tobi

I have tried to invoke a transformation/optimization pass using -mllvm, without success. I might be missing something. For example I have a shared/dynamic library which contains LLVM passes. I used to invoke them with llvmc like this: >>*llvmc mycode.c -o mycode.o -c -opt -Wo,=-load,libFoo.dylib,-Foo* Can this style of optimization be executed using -mllvm argument? Thx, PMon On Sun,

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. Some examples illustrating the features you requested: > 2. If the user has specified to generate the final

On Thu, Oct 27, 2011 at 7:31 AM, Harel Cain <harel.cain at gmail.com> wrote: > Hi all, > > A few different though somewhat related questions here. I'm really grateful > for your answers! > > 1. From a previous question I know that sizeof's are resolved into literals > early in the front-end before IR is even emitted. It seems that they are > resolved into

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

> I'll be happy to answer any further questions you may have, feel free to e-mail > me directly (though right now our mail server is down) > The salient features that we want to have in the driver are: 1. llvm-ld will be used as "The Optimizer". 2. If the user has specified to generate the final executable, then llvm-ld should run on all the .bc files generated by clang

Hi all, A few different though somewhat related questions here. I'm really grateful for your answers! 1. From a previous question I know that sizeof's are resolved into literals early in the front-end before IR is even emitted. It seems that they are resolved into whatever value is correct for the host machine. But if one wishes to then take the IR and emit assembly code for some other

Hi all, I've been subscribed to this list on-and-off and always found it very helpful. I'm facing the problem of compiling a project in Objective C with LLVM in a Darwin environment. There is a certain Objective C protocol that appears in two .m files, and so the corresponding l_OBJC_PROTOCOL and l_OBJC_LABEL_PROTOCOL symbols appear in both .o files. The problem is that while these

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

Hi, I encountered an issue with inline assembly in my c files compiled with llvmc. When I have a push instruction in the inline assembly like: __asm__ volatile ( "push {r4}\n\t" ); the compiler will drop the curly braces and leave it in the generated assembly file as: push r4 And this is non-conformant with the ARM

I see now that this clearly to the problem raised elswhere, for example: http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-December/036764.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036289.html So clearly a repeating issue on the MacOS platform. Harel On Sun, Dec 12, 2010 at 5:10 PM, Harel Cain <harel.cain at gmail.com> wrote: > Hi all, > > This is a problem

Hi all, This is a problem that occurs for me only on Darwin (MacOS) and not on Linux. When llvm 2.8 (or 2.9) is compiled with ENABLE_OPTIMIZED=1, the "opt" tool fails to load LLVM passes in dynamic libraries (.dylib) files, regardless of how they themselves were built. When opt is built with ENABLE_OPTIMIZED=0, all is well. Here is some informative output. Seems to me the problem is

Thanks for the answers. > See http://llvm.org/docs/FAQ.html#platformindependent . If you're > dealing with C code, it isn't too hard to add a new target to clang; > send an email to cfe-dev if you need help with that. The "target > datalayout" information is purely a hint to the optimizers. My experience this far has been mainly with using llvm-gcc and llvmc,

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. tools/llvmc/plugins/Base/Base.td hardcodes the -relocation-model=pic option into invocations of llc: def llc : Tool< [(in_language "llvm-bitcode"), (out_language "assembler"), (output_suffix "s"), (cmd_line

Hi Harel, Several existing passes can take command line arguments. Have a look at lib/Transforms/Scalar/LoopUnrollPass.cpp for example. Its command line arguments are defined using the cl::opt objects. Best regards, -- Arnaud de Grandmaison ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Harel Cain Sent: Thursday, January

A follow-up question: Is there a way to make different passes accept one command line option that will affect all of them? For example, I'd like to have a -optStrength parameter, that can be given to all of my passes simultaneously. Thanks a lot, Guy Arnaud Allard de Grandmaison wrote: > > Hi Harel, > > Several existing passes can take command line arguments. Have a look at

Hi all, I was wondering if there's any way to pass command line arguments to LLVM optimization passes when run through the opt tool. For example, suppose I register called MyPass, then I want to run opt -load libMyPass.so -MyPass 3 < input.bc and have "3" be available to MyPass as a kind of argv argumnet through some method. Or does it take a major rewrite of the opt tool

You could make the cl:opt object visible outside one of your passes, and use it in your other passes : in other words, it is a global variable shared between several files. Best regards, -- Arnaud de Grandmaison -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of guyadini Sent: Thursday, January 27, 2011 12:38 PM To: llvmdev at