similar to: [LLVMdev] Resolving sizeof's; target triples; type optimizations

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,

Hello > In doing this, I'm essentially overriding any "target triple" existing in > the IR, breaking up the process into a multi-stage operation (llvm-gcc, opt > and llc running independently) and picking whatever target I want, right? No. This won't work since, as indicated in the FAQ entry IR derived from C/C++ is not target neutral, so you cannot 'just'

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?

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

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

> 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

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

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

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

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

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

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:

Another question today: an array of string literals in my C program was transformed to independent global variables, each holding one string, and another array of getelementptr's to them, here it is: @words= global [5 x i8*] [ i8* getelementptr ([10 x i8]* @.str11, i32 0, i32 0), i8* getelementptr ([6 x i8]* @.str12, i32 0, i32 0), i8* getelementptr ([7 x i8]* @.str13, i32 0, i32 0), i8*