http://blog.gmane.org/gmane.comp.compilers.llvm.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50108 <pre>Hi guys, In next three years I'm going to get the scientific degree in System programming. That's why I'm looking for the interesting and actual theme not like a new bicycle with square rings. My degree work in university was connected with value range propagation (VRP) functionality in clang static analyzer based on AST. I founded it rather interesting and want to follow this direction with your project. As i know, VRP is a not new theme, and llvm and gcc projects already have the similar feature. It would be nice, if you suggest me good theme or give me the area where I could find it. -- Best regards, Sergey _______________________________________________ LLVM Developers mailing list LLVMdev&lt; at &gt;cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev </pre> Serg Anohovsky 2012-05-26T07:11:16 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50107 <pre>Hi, I have a custom scheduler/bundler running just after coalescing as proposed by the current infrastructure of machine schedulers. Btw, great thanks for this cool stuff ! I'm running into problems when I want to update the LI information of an instruction. I call handleMoveIntoBundle() to make its LI begins from the packet header but the following assertion is raised: "Can't have two defs for the same variable exiting a bundle." in moveExitingFromInto() IIUC, handleMoveIntoBundle collects entering, internal and exiting live ranges from the bundle and group all this information into BundleRanges. Then it collects the same information for the incoming instruction and add it to the current BundleRanges while updating its live ranges. I found that entering, internal and exiting live ranges of the packet are not cleared before collecting the same information for the incoming instruction. The attached patch fix it. Unfortunately, I can't provide a test case but it can be easily tested by calling handleMoveIntoBundle() with 2 arbitrary MI's where the packet contains a register def. Ivan _______________________________________________ LLVM Developers mailing list LLVMdev&lt; at &gt;cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev </pre> Ivan Llopard 2012-05-25T22:52:06 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50104 <pre>I want to generate LLVM functions that meet the C ABI for function calls/returns (preferably on multiple platforms but x86_64 would be OK for now). I know that LLVM doesn't handle this completely automatically (e.g. the type {i32,i32} should be passed as a single i64 on x86_64 linux). Is there any library that automates the generation of function declarations meeting the ABI and emit marshalling/demarshalling code from LLVM's types? I would imagine that Clang needs to do this internally, where does this code live? Thanks for your help! Zach </pre> Zach Devito 2012-05-25T18:29:58 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50099 <pre>A change has just been committed that changes the interface for TargetLowering::LowerCallTo and TargetLowering::LowerCall. Instead of passing a mess of parameters to these functions, a new structure has been created that encapsulates these parameters. The motivation is that additional fields can be added to this structure (with appropriate changes to SelectionDAGBuilder for populating the new fields) without forcing an ABI change on each and every target. In-tree targets have been updated accordingly, so no change is required. However, if you have an out-of-tree target that is following trunk, please be aware that this *will* break your build. Please see any in-tree target for the new interface and how to access the values that used to be available as individual function parameters. As a quick example, the ARM implementation for LowerCall is now: SDValue ARMTargetLowering::LowerCall(TargetLowering::CallLoweringInfo &amp;CLI, SmallVectorImpl&lt;SDValue&gt; &amp;InVals) const { SelectionDAG &amp;DAG = CLI.DAG; DebugLoc &amp;dl = CLI.DL; SmallVector&lt;ISD::OutputArg, 32&gt; &amp;Outs = CLI.Outs; SmallVector&lt;SDValue, 32&gt; &amp;OutVals = CLI.OutVals; SmallVector&lt;ISD::InputArg, 32&gt; &amp;Ins = CLI.Ins; SDValue Chain = CLI.Chain; SDValue Callee = CLI.Callee; bool &amp;isTailCall = CLI.IsTailCall; CallingConv::ID CallConv = CLI.CallConv; bool doesNotRet = CLI.DoesNotReturn; bool isVarArg = CLI.IsVarArg; The CallLoweringInfo struct now contains all parameters that were originally available as parameters. The InVals vector was left as a parameter since it is the responsibility of the LowerCall implementation to fill it and does not represent input information about the call (unlike IsTailCall which is an in/out parameter, and hence added to the new struct). ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- _______________________________________________ LLVM Developers mailing list LLVMdev&lt; at &gt;cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev </pre> Justin Holewinski 2012-05-25T16:59:27 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50089 <pre>Hi, On AMD GPUs we have source modifiers and output modifiers, which are bits you can set on instructions to perform some simple no cost operations on either the operands or the result of an instruction (floating point values only). The source modifiers are FABS and FNEG and are applied to the operands before an instruction is executed. The output modifiers are CLAMP (clamp result between 0.0f and 1.0f) and OMOD (multiply the result by 0.5f, 2.0f, or 4.0f). These are applied to the result of an instruction after it is executed. For the R600 backend, I'm using the MachineOperand TargetFlags to keep track of the modifiers, but I've noticed when I use them on operands to COPY instructions they are not propagated when registers are coalesced. Is this a bug, or should I not be using TargetFlags for storing this kind of information? -Tom </pre> Tom Stellard 2012-05-25T15:15:08 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50066 <pre>Dear Sir, I am trying to compile llvm (llvm, clang, compiler-rt) package. I got an errors: /llvm/projects/compiler-rt/lib/tsan/rtl/tsan_defs.h:144:9: error: expression result unused; assign into a variable to force a volatile load [-Werror, -Wunused-volatile-lvalue]. Same errors in lines 145 and 146 ((void) cfg; (void)stats; (void)shadow). OS: RHEL 6.2 (x86-64) GCC: 4.4.6 Compiled with optimization enabled flag. Also some tests (make check-all) finished unsuccessful. Could you please help with this issue? - Andrey </pre> Andrey Pudov 2012-05-24T20:27:06 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50063 <pre>Hello, I've recently finished moving a cross-platform project to LLVM 3.0 and now transitioning to 3.1. One of the things I've hit is on OS X, I have linker errors involving JITEventListener and I've noticed if I move the JITEventListener destructor out of JIT.cpp and into JITEventListener.h (like other functions of JITEventListener), the linker is much happier. I'd like to push this change back to LLVM trunk if people think it is good. What do I need to do to gain blessings and permission to do this? Aaron Dwyer Imagination Technologies _______________________________________________ LLVM Developers mailing list LLVMdev&lt; at &gt;cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev </pre> Aaron Dwyer 2012-05-24T20:55:30 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50062 <pre> I wonder why AVX is not used automatically if available at the host machine. In contrast to that, SSE41 instructions (like pmulld) are automatically used if the host machine supports SSE41. E.g. $ cat avx.ll define void &lt; at &gt;_fun1(&lt;8 x float&gt;*, &lt;8 x float&gt;*) { _L1: %x = load &lt;8 x float&gt;* %0 %y = load &lt;8 x float&gt;* %1 %z = fadd &lt;8 x float&gt; %x, %y store &lt;8 x float&gt; %z, &lt;8 x float&gt;* %0 ret void } $ llc -o - avx.ll .file "avx.ll" .text .globl _fun1 .align 16, 0x90 .type _fun1,&lt; at &gt;function _fun1: # &lt; at &gt;_fun1 .cfi_startproc # BB#0: # %_L1 movaps (%rdi), %xmm0 movaps 16(%rdi), %xmm1 addps (%rsi), %xmm0 addps 16(%rsi), %xmm1 movaps %xmm1, 16(%rdi) movaps %xmm0, (%rdi) ret .Ltmp0: .size _fun1, .Ltmp0-_fun1 .cfi_endproc .section ".note.GNU-stack","",&lt; at &gt;progbits $ llc -o - -mattr avx avx.ll .file "avx.ll" .text .globl _fun1 .align 16, 0x90 .type _fun1,&lt; at &gt;function _fun1: # &lt; at &gt;_fun1 .cfi_startproc # BB#0: # %_L1 pushq %rbp .Ltmp2: .cfi_def_cfa_offset 16 .Ltmp3: .cfi_offset %rbp, -16 movq %rsp, %rbp .Ltmp4: .cfi_def_cfa_register %rbp vmovaps (%rdi), %ymm0 vaddps (%rsi), %ymm0, %ymm0 vmovaps %ymm0, (%rdi) popq %rbp vzeroupper ret .Ltmp5: .size _fun1, .Ltmp5-_fun1 .cfi_endproc .section ".note.GNU-stack","",&lt; at &gt;progbits I guess your answer is that I did not specify a target triple. However why is SSE41 automatically detected and AVX is not? </pre> Henning Thielemann 2012-05-24T20:19:41 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50061 <pre>Hello everyone At EuroLLVM I presented some testing work we have been doing on improving correctness of the MC Layer for ARM. There seemed to be interest from the community in seeing the results of this test suite. Background ----------- We are using a test suite, called MC Hammer, that compares MC with an ARM in-house implementation of the same functionality. The test space for this suite is very large ( O(10 trillion) points ) so we are concentrating on small slices at a time. For further details you can check out the talk I did at EuroLLVM last month: http://llvm.org/devmtg/2012-04-12/Slides/Richard_Barton.pdf Results -------- The below results are: - for Thumb instructions - for Cortex-A8 with VFPv3 and Advanced SIMDv1 extensions - for the encode/decode loop, described on slide 11 of the talk - all silent codegen bugs[1], that is bugs where: - The reference bitpattern is defined and predictable. - The generated bitpattern is defined. - The generated bitpattern differs from the reference bitpattern. - for LLVM r157187 (updated at 2012-05-21 14:18:06 BST.) - for LLVM built with no assertions[2] The full log from MC Hammer is very large (&gt;16GB) this is theoretically available on request. Of more interest, is the attached triaged summary of these logs, showing that there are six bugs of this kind found (summary from log reproduced below [3]). If anyone is interested in seeing the results for any particular slice of the test space then I will consider requests. Regards, Richard Barton ARM Ltd, Cambridge ==================== [1] Other types of failure can be detected by MC Hammer. These results can be published if there is interest in seeing them. [2] LLVM built with assertions turned on hits SIGABRT on some bitpatterns. When this occurs the rest of the slice is not run, so to cover the whole slice we are using an version of LLVM with no assertions. One would expect an assertion to catch early a genuine codegen failure so hopefully bugs that would have triggered an assertion will still show up without them on. [3] (reproduced bug triage from the error output) [bug 1] - Decode for T1 B&lt;c&gt; encoding does not sign extend the 8-bit immediate properly reproduce with: echo 0x40 0xd0 | .../llvm-mc -triple thumbv7 -show-encoding -disassemble -show-inst The re-encoding has an incorrect offset when the 6th bit of the immediate is set. A look at the code shows that the decoder uses a C++ cast to signed integer rather than calling the SignExtend function. [bug 2] - STRD with negative offset re-encodes to positive offset and disassembles with no offset reproduce with: echo 0x61 0xe9 0x00 0x00 | .../llvm-mc -triple thumbv7 -show-encoding -disassemble -show-inst Any encoding with the U bit unset, re-encodes to the equivalent instruction with the U-bit set. [bug 3] - FSTMX/FLDMX not supported This is similar to the already reported bug in the ARM encoding slice. These are pre-UAL representation of VLDM/VSTMs with bit 0 set to 1 (an odd first register in the list) that are still available in ARMv7. [bug 4] - B.W immediate is not being encoded correctly. I1 and I2 are not being decoded correctly echo 0x00 0xf0 0x00 0xb0 | .../llvm-mc -triple thumbv7 -show-encoding -disassemble -show-inst This is the T4 encoding of the wide branch instruction. The branch target is encoded as SignExtend(S:(NOT(J1 EOR S)):(NOT(J2 EOR S)):imm10:imm11:0, 32) the current implementation missed out the EOR-ing. [bug 5] - PLD with -ve offset is re-encoding to have +ve offset reproduce with: echo 0x1f 0xf8 0x01 0xf0 | .../llvm-mc -triple thumbv7 -show-encoding -disassemble -show-inst [bug 6] - VST1.16 with alignment 16 is re-encoded to unaligned reproduce with: echo 0x80 0xf9 0x10 0x04 | ../build-none/bin/llvm-mc -triple thumbv7 -show-encoding -disassemble -show-inst Richard Barton ARM Ltd, Cambridge Running slice: core_v7A+vfpneon_vfpv3_neonv1 feature_Thumb 0x00000000 - 0xffffffff encode_decode FAILED[0000 0000 0000 0000 1101 0000 0100 0000, 0xd040]: Member differs: 'immediate' (BEQ {pc}+0x84 ; 0x84)[hit 1792 times] [[bug 1] - Decode for T1 B&lt;c&gt; encoding does not sign extend the 8-bit immediate properly] FAILED[0000 0000 0000 0000 1110 1000 0110 0001, 0xe861]: Member differs: 'loadStoreMode' (STRD lr,r8,[r1],#-0x184)[hit 42 times] [[bug 2] - STRD with negative offset reencodes to positive offset and disassembles with no offset] FAILED[1110 1100 1000 0000 0000 1011 0000 0011, 0xec800b03]: Member differs: 'minorOpcode' (FSTMIAX r0,{d0})[hit 12240 times] [[bug 3] - FSTMX/FLDMX not supported] FAILED[1111 0000 0000 0000 1001 0000 0000 0001, 0xf0009001]: Member differs: 'immediate' (B {pc}+0xc00006 ; 0xc00006)[hit 16777215 times] [[bug 4] - B.W immediate is not being encoded correctly. I1 and I2 are not being decoded correctly] FAILED[1111 1000 0001 1111 1111 0000 0000 0000, 0xf81ff000]: Member differs: 'loadStoreMode' (PLD [pc,#-0])[hit 64 times] [[bug 5] - PLD with -ve offset is re-encoding to have +ve offset] FAILED[1111 1001 1000 0000 0000 0100 0001 0000, 0xf9800410]: Member differs: 'vldstAlign' (VST1.16 {d0[0]},[r0&lt; at &gt;16],r0)[hit 15360 times] [[bug 6] - VST1.16 with alignment 16 is re-encoded to unaligned] 4294967296 bitpatterns tested, 4025094892 passed, 134277915 failed, 146552531 skipped (3.13% failure rate) Failure breakdown: Not assembled: 0 Not disassembled: 0 Should be unpredictable: 132606598 (3.09%) Should be undefined: 10639863 (0.24%) Should not be unpredictable: 455 (0.00%) Should not be undefined: 5169418 (0.12%) Member differs: 134277915 (3.13%) Other: 0 _______________________________________________ LLVM Developers mailing list LLVMdev&lt; at &gt;cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev </pre> Richard Barton 2012-05-24T18:18:48 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50049 <pre>Hi all, In our architecture, there is a set of general purpose registers which could be used to store integer and floating point numbers. My problem is how to correctly specify the type of this register class. For now, its type is specified as i32, and it is problematic if it is used in floating point instructions, since tablegen cannot correctly infer the type information of such a pattern. Here is an example: // Definition of the register class def RegCRF : RegisterClass&lt;"Foo", [i32], 32, (sequence "R%u", 0, 255)&gt;; // Tablegen: error: In FADD: Type inference contradiction found // no floating point types found def FADD : InstFoo&lt;(outs RegCRF:$d), (ins RegCRF:$a, RegCRF:$b), "FADD\t$d, $a, $b", [(set RegCRF:$d, (fadd RegCRF:$a, RegCRF:$b))]&gt;; I also tried to type RegCRF as [i32, f32], but then the type inference error appears in my load/store instructions, when RegCRF is used as an address operand. So what is the correct way to solve this problem? Thank you in advance! Regards, Lei Mou </pre> Lei Mou 2012-05-24T14:25:36 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50043 <pre>Hi, all When I have a loop unrolled, in the loop body, the same element of the array may be accessed multiple times. I see there are then load and store instructions and I can no longer trace the data dependency directly by comparing the operands. So I am writing to see if anyone has done this or any methods in llvm that may help? Best regards, </pre> Cheng Liu 2012-05-24T11:07:33 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50027 <pre>Hi all. I found that if you want to use grep with escape characters in lit, you should pass it within the double slash (\\). Since the first one is captured by python scripts and the second one by grep. E.g. if you want to capture "grep icmp ule" you should pass "grep icmp\\ ule" So I'm going to commit the test with strings like this. How stable this feature in lit? -Stepan. </pre> Stepan Dyatkovskiy 2012-05-24T07:12:47 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50024 <pre>Hi all, I was trying to use LTO facility of LLVM to reduce the footprint of Clang itself. I build the ld-gold  and LLVMgold.so as described at [1] and then set the environment as described too. However, had to add the path for plugin manually as Clang was not able pass it to ld automatically. Following is the setting I used before starting to build (small foot Clang. CXX=clang++ -flto -Wl,--plugin=/home/wer/llvm-3.0/build_config_gold_release/Release/lib/LLVMgold.so CFLAGS=-O3 CC=clang -flto -Wl,--plugin=/home/wer/llvm-3.0/build_config_gold_release/Release/lib/LLVMgold.so RANLIB=/bin/true Then configured and did the build for LLVM. While building Clang tool, there may be large part of LLVM/Clang libraries which are not used by Clang. So I was expecting appreciable reduction in size for Clang. However memory savings were minimal. Also, as explained in [2] in the topic "Compiler driver invokes link time optimizer separately." , there are many cases when invoking Clang with -flto may not remove the dead code. However I cannot figure out how to build the Clang with first compiling all files to LLVM bit code and then allow linker to treat them as compiled binaries which can be linked together with LTO pass. If this is possible by changes in Makefiles or build system, it can help me a lot in removing some generic parts in Clang too to make a less generic but lighter compiler tool. Please help me with the same. Thanks, Ankur [1] http://llvm.org/docs/GoldPlugin.html [2] http://llvm.org/docs/LinkTimeOptimization.html </pre> ankur deshwal 2012-05-24T04:34:46 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50023 <pre>Here are the results of me playing around with the new EXPERIMENTAL release v3.1 of clang for Windows using MinGW32: 0. You don't need to go through the nightmare of building clang v3.1 yourself - it is right there on the download page, albeit at the very bottom. 1. Install MinGW32 in the directory C:\MinGW and nowhere else. Otherwise you'll get all sorts of errors about missing include files and nothing will work at all. 2. Install all of MinGW32 - MSYS and all of the packages, just to be sure it all works. 3. Install Clang in a directory without spaces in it (as the clang docs say). 4. Add both c:\MinGW\bin and clang's bin directory to your path using the PATH command: path c:\tmp\clang-3.1-win32-mingw32\bin;c:\MinGW\bin;%path% 5. Be prepared to have to edit your source files a little as MinGW32 is not entirely Microsoft compatible (there's no GetFileSizeEx() function, for instance). 6. Remember to use MinGW's ranlib, not llvm-ranlib, when you create an indexed archive. The latter won't work and MinGW's ld will reject the library. Sample session: clang++ -c -o a.o a.cpp clang++ -c -o b.o b.cpp llvm-ar rcs Test.lib a.o b.o ranlib Test.lib clang++ -o c.exe c.cpp Test.lib Other than that, I have no comments. I managed to build a support library without problems and the module tests ran without any problems. I have not yet had time to play around with LLVM v3.1. P.S. Thank you guys, it is wonderful that you are now (again) making a binary release for Windows. I think it is the first step in getting rid of the EXPERIMENTAL tag :-) P.P.S. And a quick, voiced prayer that we'll one day see a distro of clang for MinGW64 as well. If I ever figure out how to build it, I'd be happy to build it for release purposes. Cheers, Mikael _______________________________________________ LLVM Developers mailing list LLVMdev&lt; at &gt;cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev </pre> Mikael Lyngvig 2012-05-24T02:32:15 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50022 <pre>Hi guys, Does getPointerSizeInBits need to return sizeof(void*) in Platform? I found that getPointerSizeInBits return 8 in x86-32 on win7-64, MSVC 2010. And if I have a struct { i32, i32* }; the structLayout-&gt;getElementOffset(1) return 8, but I think 4 is right. In generated ASM, the offset of second element is 4. Thanks. </pre> 空明流转 2012-05-24T01:43:33 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50018 <pre>Hi, I recently tried to follow the instructions on http://vmkit.llvm.org/get_started.html but all I get is </pre> Patrik Plihal 2012-05-24T00:18:20 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50016 <pre>Hi again again, I'm trying to build my compiler frontend in C++ on Windows 7 x64 using clang++.exe. I want to use clang++ for my project so that I get a feel for how mature and usable the Windows support is as I gradually get up to speed with LLVM for Windows. I could develop on Linux, but I need the Windows support so I figure I might as well do it the hard way. My code is fairly simple C++ with a few template classes, a rare virtual function, and nothing very fancy. I am able to compile my code without warnings (although clang++ earlier on found a couple of very serious issues in my code). But when I get to the link phase, all hell breaks loose: I get a ton of these warnings: Memory.o : warning LNK4006: _InterlockedBitTestAndSet already defined in Stream.o; second definition ignored Memory.o : warning LNK4006: _InterlockedBitTestAndReset already defined in Stream.o; second definition ignored Memory.o : warning LNK4006: _InterlockedBitTestAndComplement already defined in Stream.o; second definition ignored Memory.o : warning LNK4006: _MemoryBarrier already defined in Stream.o; second definition ignored Memory.o : warning LNK4006: _ReadPMC already defined in Stream.o; second definition ignored I don't use InterlockedBitTestAndSet anywhere in my code and the same goes for the rest of the symbols that are being warned about. After that, I get a ton of errors form the linker because it complains about the above symbols already being defined. I also get a few errors like this: Bitset_test-423377.o : error LNK2001: unresolved external symbol __ZTVN10__cxxabiv120__si_class_type_infoE Any ideas? Is the Windows support simply not mature enought for real use or am I doing something wrong? I invoke the linker through clang++ by giving the input object files and a library that must be linked against, made with Microsoft's LIB tool. I use Microsoft LIB because LINK rejects libraries created using llvm-ar. I only use the -c, -o, -v, and -D options to clang++.exe and nothing else. Nothing advanced yet. Is it that clang++/Windows simply don't support the use of libraries yet? The hello world example works great, but I do aspire to more than that. If I have missed an important note in the documentation, then I apologize greatly in advance. Sincerely, Mikael Lyngvig _______________________________________________ LLVM Developers mailing list LLVMdev&lt; at &gt;cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev </pre> Mikael Lyngvig 2012-05-23T23:38:05 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50015 <pre>Hi, I'm implementing the alloc_size function attribute in clang. This attribute exists in gcc since version 4.3. The attribute specifies that a function returns a buffer with the size given by the multiplication of the specified arguments. I would like to add new metadata to pass this information to LLVM IR. For example, take the following C code: void* my_calloc(size_t, size_t) __attribute__((alloc_size(1,2))); void* fn() { return my_calloc(1, 3); } which would get translated to: define i8* &lt; at &gt;fn() { entry: %call = call i8* &lt; at &gt;my_calloc(i32 1, i32 3), !alloc_size !0 ret i8* %call } declare i8* &lt; at &gt;my_calloc(i32, i32) !0 = metadata !{i32 0, i32 1} The downsize is that the metadata is added to all call sites, since it's not possible to attach metadata to function declarations. Any comment, suggestion, etc? Thanks, Nuno </pre> Nuno Lopes 2012-05-23T23:16:30 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50014 <pre> I want to generate Haskell bindings to LLVM intrinsics. In a first attempt I wrote a little parser that reads IntrinsicsX86.td and outputs a Haskell module. E.g. the definition def int_x86_avx_max_ps_256 : GCCBuiltin&lt;"__builtin_ia32_maxps256"&gt;, Intrinsic&lt;[llvm_v8f32_ty], [llvm_v8f32_ty, llvm_v8f32_ty], [IntrNoMem]&gt;; is turned into maxpd256 :: Ext.T (V4Double -&gt; V4Double -&gt; LLVM.CodeGenFunction r V4Double) maxpd256 = Ext.intrinsic ExtX86.avx "max.pd.256" This works for the flat structure of IntrinsicsX86.td, but e.g. IntrinsicsPowerPC.td uses tablegen classes. Now I wonder whether it is better to use tablegen to generate the Haskell code. The tblgen man page says, that tablegen emits C++. This would not be a big problem, since I could let it write C++ code that in turn writes Haskell code. Unfortunately the section "http://llvm.org/docs/TableGenFundamentals.html#backends" is not yet written. Is it possible to use the llvm-tblgen binary without modification or do I have to extend llvm-tblgen or do I have to write my own C++ code that uses some of the functions from the tblgen library? Are there any (simple) examples of custom tblgen backends? </pre> Henning Thielemann 2012-05-23T22:38:13 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50013 <pre>Hi again, The Visual Studio getting started guide ( http://llvm.org/docs/GettingStartedVS.html) mentions the "llvm-lit" tool, but fails to mention these things: 1. Either you need to run it from bash or a similar Unix shell, as Windows does not recognize the extensionless Python script that it is. 2. Alternatively, you can invoke it using Python like this: python bin/llvm-lit test I know that the documentation says that I am to install GnuWin32 tools, but I strongly oppose that idea. We Windows people have our own tools and practices and I think the LLVM developers should open up to a more multi-platform approach than the current (Unix then, perhaps maybe, Windows) approach. CMake works brilliantly, though, so there are no issues in building neither the win32 or win64 versions of LLVM. As far as I can tell, I don't need the GnuWin32 tools at all. I can succesfully build and link a tiny "hello world" sample program without problems. I do have many Windows ports of Unix tools in my standard path, though, and perhaps that is the reason that the build succeds without GnuWin32. If I can help, please let me know. My angle to LLVM is this: I need a portable, multi-targeting code generator and optimizer, and I happen to prefer Windows as my platform. So, perhaps I can write or update some documentation on how to use LLVM on Windows. Sincerely, Mikael Lyngvig _______________________________________________ LLVM Developers mailing list LLVMdev&lt; at &gt;cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev </pre> Mikael Lyngvig 2012-05-23T21:50:06 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/50012 <pre>Hi, I am building LLVM v3.0 for Windows 32-bit and 64-bit, and when I extract the files from the tar archive, I get the following error: ********************* c:\tmp\llvm-3.0.src-win32\tools&gt;tar xzf \tmp\clang-3.0.tar.gz clang-3.0.src/tools/scan-build/c++-analyzer: Can't create 'clang-3.0.src/tools/scan-build/c++-analyzer': No such file or directory tar: Error exit delayed from previous errors. c:\tmp\llvm-3.0.src-win32\tools&gt;tar --version bsdtar 2.4.12 - libarchive 2.4.12 ************************ As you can see, I use BSD tar instead of GNU tar because of the former supports more file formats and for other reasons I can't recall right now. I don't know if the problem is caused by BSD tar or not. I don't even know what the precise problem is, but I guess tar is being instructed to create a link. I don't think the above warrants a bug report; perhaps whoever's responsible for creating the distribution tars can take the above into consideration when preparing the archives? I do not know that the above should have caused any problems for me in any way; I can build fine and the output seems to run more or less sanely (I still get some odd behavior from clang++, but that's probably due to one or more errors on my part). Sincerely, Mikael Lyngvig _______________________________________________ LLVM Developers mailing list LLVMdev&lt; at &gt;cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev </pre> Mikael Lyngvig 2012-05-23T21:18:25 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.compilers.llvm.devel