similar to: [LLVMdev] Preventing long longs in C backend

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

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,

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, 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

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

Hi all, Working with llvm 2.8 installed on Mac OS, when using the llvm-gcc frontend and the C backend I see it converting regular (non-checking) memcpy and memset calls to __memset_chk and __memcpy_chk already at the IR stage. Then in the CBE output these are retained as gcc builtin functions. In a similar manner, llvm.objectsize.* calls are replaced with __builtin_object_size calls, another gcc

Hi all, I couldn't find any reasonable way to create the IntegerType that would match, say, intptr_t, that is the native word size of the machine I'm building on. More accurately defined, when compiling on a 64 bit Mac OS machine I want it to be Int64Ty, but if for example I'm using the "-arch i386" command line option on that machine during compilation, I want it to be

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

The llvm compiler can now generated movt/movw instructions to create 32-bit constants. Those new instructions use new relocations. Mach-o uses different numbering for relocations than ELF does. For mach-o, ARM_RELOC_PAIR=1 and ARM_RELOC_HALF=8. You need a newer linker that understands the new relocations. -Nick On Feb 20, 2012, at 5:20 AM, Harel Cain wrote: > Hi all, > > I'm

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?

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, 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

On 14/07/2009, at 12.35, Harel Cain wrote: > When using "make check" with the DejaGNU test collection, I encounter > two unexpected failures (they seem to be closely related). > My question: are they well known, and if so what's the problem and how > can I fix it? > FAIL: /var/data/common/trunk/llvm/test/FrontendC/2008-05-19- > AlwaysInline.c > FAIL:

Hi all, When using "make check" with the DejaGNU test collection, I encounter two unexpected failures (they seem to be closely related). My question: are they well known, and if so what's the problem and how can I fix it? This is the error text I get: FAIL: /var/data/common/trunk/llvm/test/FrontendC/2008-05-19-AlwaysInline.c Failed with exit(1) at line 1 while running:

Hi all, I'm trying to figure out a problem with relocation types 1 and 8 (as observed using otool -r on ARM/Thumb object files). Earlier, when I used LLVM 2.8 with llc to generate thumb (-march=thumb -mattr=+thumb2) assembly listings, then assemble those using the gcc of iPhone 4.2 SDK, there wasn't any problem. However starting with LLVM 2.9, the same toolchain emits slightly different

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

Hi all, 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? Thanks! Harel Cain -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120304/0e5c7267/attachment.html>

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

Hi all, I'm trying to prevent two things from happening: 1. Intrinsic memcpy calls of for example 16 bytes in the IR code being translated into movl commands in x86 assembly code, for example, this code: call void @llvm.memcpy.p0i8.p0i8.i32(i8* %3, i8* getelementptr inbounds ([16 x i8]* @.str1, i32 0, i32 0), i32 16, i32 1, i1 false) translated into this x86 assembly movl