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/62514 <pre>So I just started looking into LLVM and I was wondering how to install the LLVM tools suite. (Such as the llvm-as or lli commands in the terminal described here: http://llvm.org/docs/CommandGuide (http://llvm.org/docs/CommandGuide/)). I have downloaded LLVM, Clang, the test suite, and have run the build and make commands. I have looked around on the website but I have not found a sufficient explanation of how to install the tools. If it is on there, feel free to send a link, but if not I would greatly appreciate any help. Thanks, Kyle _______________________________________________ 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> Kyle Holzinger 2013-05-24T22:27:09 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/62503 <pre>Hi all, I am experiencing a problem managing the command line option of a set of passes in my LLVM project. Attached you find a toy project the triggers the problem. The project is made up of two passes: "AnalysisPass" and "TransformPass". "TransformPass" requires "AnalysisPass" and they both share a common integer command line option called "-command-line-option" According to: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-January/037722.html the proper way of sharing a cl::opt variable among multiple passes is to define the variable once and declare it as "explicit" in all the files of the passes that need it. To keep the project tidy the two "AnalysisPass" and "TransformPass" are compiled into two different .so libraries. The only way I can think of to share the cl::opt variable is to define is to define it in a separate "Support" static library which is then linked by both "AnalysisPass" and "TransformPass". When running "AnalysisPass" loading it with opt all works fine, while running "TransformPass" opt never returns stuck in an infinite loop. GDB tells me that opt is trapped somewhere into llvm::cl::ParseCommandLineOptions, but I am not confident with command line option management. Notice that if the cl::opt variable is not used at all in "TransformPass" everithing runs fine. Does anybody have an idea on what is going on here ? Is there a better way of sharing command line options among passes belonging to different libraries ? Thank you in advance. Cheers, Alberto _______________________________________________ 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> Alberto Magni 2013-05-24T16:38:44 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/62496 <pre>hi list, SHARC, is a kind of DSP Processor from ADI. Who are making a backend for it, or already have one? If your code's not for business, would you mind share it for me? even incomplete is appreciated. Thanks, all. linduan&lt; at &gt;isoftstone.com _______________________________________________ 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> Duan,Lin 2013-05-24T09:24:43 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/62495 <pre>Hello, here is a patch to add Thumb call relocation to the dynamic linker. I would be happy if you could commit it to the SVN. Thank you, Jonas _______________________________________________ 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> Jonas Zaddach 2013-05-24T09:12:25 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/62493 <pre>Hi all I received the following patch for compiling ctypes module for Python on FreeBSD from Keith White (I'm in no position to judge this fix, I'm just passing it on). Is there anyone on this list being able to commit this code? Thxs, Werner =================================================================== --- contrib/compiler-rt/lib/clear_cache.c (revision 250739) +++ contrib/compiler-rt/lib/clear_cache.c (working copy) &lt; at &gt;&lt; at &gt; -21,6 +21,23 &lt; at &gt;&lt; at &gt; * specified range. */ +/* python ffi routines call it too */ + +#if defined(__arm__) &amp;&amp; defined(__clang__) +#pragma redefine_extname __clear_cache_c __clear_cache +void __clear_cache_c(void* start, void* end) +{ + extern int sysarch(int number, void *args); + struct + { + unsigned int addr; + int len; + } s; + s.addr = (unsigned int)(start) &amp; ~0x1f; + s.len = (int)((((unsigned int)end + 0x1f) &amp; ~0x1f) - ((unsigned int)start &amp; ~0x1f)); + (void) sysarch (0, &amp;s); +} +#else void __clear_cache(void* start, void* end) { #if __i386__ || __x86_64__ &lt; at &gt;&lt; at &gt; -37,4 +54,5 &lt; at &gt;&lt; at &gt; #endif #endif } +#endif </pre> Werner Thie 2013-05-24T06:17:35 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/62491 <pre>Is it possible to run test-suite as one step starting with clang? I.e. not run clang and then llc. I think that lnt can do this but lnt's stated purpose is to be a performance suite so it may diverge from test-suite over time. </pre> reed kotler 2013-05-24T00:07:49 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/62465 <pre>Hi, I have a question about the definitions of t2LDRSB and t2LDRSB_PRE in ARMInstrThumb2.td : I was aware that the definitions of target RegisterClass (outs) are different in t2LDRSB and t2LDRSB_PRE. While t2LDRSB uses rGPR, t2LDRSB_PRE uses GPR. I wonder if lr and pc are already prevented from being allocated in pre-indexing case, because of some register hint that is being enforced? defm t2LDRSB : T2I_ld&lt;1, 0b00, "ldrsb", IIC_iLoad_bh_i, IIC_iLoad_bh_si, rGPR, UnOpFrag&lt;(sextloadi8 node:$Src)&gt;&gt;; def t2LDRSB_PRE : T2Ipreldst&lt;1, 0b00, 1, 1, (outs GPR:$Rt, GPR:$Rn_wb), (ins t2addrmode_imm8:$addr), AddrModeT2_i8, IndexModePre, IIC_iLoad_bh_iu, "ldrsb", "\t$Rt, $addr!", "$addr.base = $Rn_wb", []&gt; { let AsmMatchConverter = "cvtLdWriteBackRegT2AddrModeImm8"; } Thanks, Junbum </pre> Junbum Lim 2013-05-23T15:14:36 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/62456 <pre>Hello, In Rubinius we're seeing an occasional crash inside LLVM that always happens inside getenv(), which is used for example when creating a MCContext (inside lib/MC/MCContext.cpp, it checks getenv("AS_SECURE_LOG_FILE")). The problem is that getenv() and friends aren't thread safe and Rubinius provides a multithreaded system. We can relatively easily get locking setup around the getenv() calls we do in Rubinius, but that's really complex to be able to do for LLVM. I also don't know what the guarantees are here that LLVM wants to provide regarding thread safety of code that happens to have a getenv() call inside it. What would be the best approach to solving this? Would it be necessary to put locking around this inside our usage of LLVM? Should LLVM provide a locking mechanism for this or should there be a way to make the getenv() calls optional in the places there are used (like here in MCContext). Regarding the thread safety, this is what the open group says about getenv(): "The getenv() function need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe." http://pubs.opengroup.org/onlinepubs/009696799/functions/getenv.html </pre> Dirkjan Bussink 2013-05-23T13:49:55 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/62455 <pre> Below are the results for the Polyhedron 2005 benchmarks compiled with llvm/compiler-rt/dragonegg 3.3svn at r182439 against current FSF gcc 4.7.3svn and 4.8.1svn. The only major bug remaining in the dragonegg 3.3svn support for gcc 4.8.x is http://llvm.org/bugs/show_bug.cgi?id=15980 which results in unresolved symbols for _iround and _iroundf in the aermod and rnflow testcases. Note that this skews the geometric mean of the run time to much higher values. Jack Tested on x86_apple-darwin12 Compile Flags: -ffast-math -funroll-loops -O3 de-gfortran47: /sw/lib/gcc4.7/bin/gfortran -fplugin=/sw/lib/gcc4.7/lib/dragonegg.so -specs=/sw/lib/gcc4.7/lib/integrated-as.specs de-gfortran48: /sw/lib/gcc4.8/bin/gfortran -fplugin=/sw/lib/gcc4.8/lib/dragonegg.so -specs=/sw/lib/gcc4.8/lib/integrated-as.specs de-gfortran47+optzns: /sw/lib/gcc4.7/bin/gfortran -fplugin=/sw/lib/gcc4.7/lib/dragonegg.so -specs=/sw/lib/gcc4.7/lib/integrated-as.specs -fplugin-arg-dragonegg-enable-gcc-optzns de-gfortran48+optzns: /sw/lib/gcc4.8/bin/gfortran -fplugin=/sw/lib/gcc4.8/lib/dragonegg.so -specs=/sw/lib/gcc4.8/lib/integrated-as.specs -fplugin-arg-dragonegg-enable-gcc-optzns gfortran47: /sw/bin/gfortran-fsf-4.7 gfortran48: /sw/bin/gfortran-fsf-4.8 Run time (secs) Benchmark de-gfortran47 de-gfortran48 de-gfortran47+optzns de-gfortran48+optzns gfortran47 gfortran48 ac 11.39 11.39 8.09 8.14 8.18 8.05 aermod 16.35 -1.00 14.50 -1.00 16.45 16.23 air 6.88 6.79 5.42 5.25 5.83 5.73 capacita 39.85 39.85 34.71 33.39 32.51 33.02 channel 2.05 2.03 2.15 1.98 1.83 1.83 doduc 27.10 27.24 26.75 26.36 25.91 25.76 fatigue 8.85 8.88 7.72 5.56 8.26 5.60 gas_dyn 11.76 11.45 4.51 4.20 3.88 3.59 induct 24.01 24.00 11.86 11.85 12.08 12.21 linpk 15.43 15.44 15.40 15.77 15.37 15.64 mdbx 11.92 11.92 11.30 11.28 11.18 11.42 nf 29.57 29.82 29.50 29.46 27.21 27.25 protein 36.15 35.10 35.93 34.13 31.88 31.81 rnflow 27.02 -1.00 26.77 -1.00 24.67 21.21 test_fpu 11.49 11.34 9.11 9.30 7.90 8.01 tfft 1.92 1.92 1.92 1.90 1.86 1.90 Geom. Mean 13.19 21.26 10.99 17.31 10.60 10.22 Compile time (secs) Benchmark de-gfortran47 de-gfortran48 de-gfortran47+optzns de-gfortran48+optzns gfortran47 gfortran48 ac 0.62 0.31 2.20 1.38 2.88 2.08 aermod 35.19 35.52 43.50 42.89 42.75 55.97 air 1.16 1.17 2.72 2.36 4.48 4.28 capacita 0.52 0.55 1.02 0.99 1.90 1.89 channel 0.26 0.26 0.47 0.47 0.65 0.75 doduc 1.74 1.76 3.78 3.54 6.03 5.68 fatigue 0.91 0.91 1.33 1.49 1.97 2.04 gas_dyn 0.70 0.69 1.40 1.38 3.39 2.44 induct 1.95 1.73 2.87 2.98 4.08 4.42 linpk 0.25 0.24 0.53 0.71 0.92 1.25 mdbx 0.66 0.67 1.30 1.14 2.16 1.90 nf 0.39 0.39 0.80 0.74 2.12 1.67 protein 1.12 1.11 2.01 1.77 4.39 3.62 rnflow 1.26 1.26 2.93 2.74 6.43 5.47 test_fpu 0.91 0.91 2.27 2.22 5.28 4.26 tfft 0.22 0.21 0.39 0.44 0.59 0.78 Executable (bytes) Benchmark de-gfortran47 de-gfortran48 de-gfortran47+optzns de-gfortran48+optzns gfortran47 gfortran48 ac 26776 26792 47160 34928 59120 42784 aermod 1023024 0 1052728 0 1392840 1286136 air 61940 61948 65964 61876 110768 106680 capacita 41344 41144 45440 45040 77920 73248 channel 22736 22744 26696 22552 34704 34656 doduc 128376 128384 140580 136296 205320 189040 fatigue 65648 65640 69808 73848 90240 82040 gas_dyn 54840 54936 63144 71304 123680 99184 induct 163064 158792 163192 166920 179080 170872 linpk 18680 18688 22896 34920 42640 50936 mdbx 49492 49508 57692 53604 90232 78032 nf 23880 23888 32088 32104 84072 67744 protein 74960 75048 87144 83128 131976 115688 rnflow 67704 0 88248 0 205584 176912 test_fpu 50000 50008 70440 78456 179464 142608 tfft 18568 18576 18416 22544 30680 34832 </pre> Jack Howarth 2013-05-23T13:46:12 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/62449 <pre>Hi, LLVM is very useful but I am wondering if there is an interest in creating a full tool chain for language definition and compilation with IDE integration support (to be used by IDE implimenter) using a DSL perhaps using insights from projects like xtext (http://www.eclipse.org/Xtext/) and MPS (http://www.jetbrains.com/mps/). Perhaps you could use MPS code base to be able to have it translated to Clang if not LLVM byte code. May be CodeLight integration of the framework. The C++ examples and some times having to use other parsers and lexers is not very user friendly for lesser mortals who might be looking into using LLVM as a DSL back end. Even all the options are overwhelming ideally should be defined as part of the language design process. Suminda -- Suminda Sirinath Salpitikorala Dharmasena, B.Sc. Comp. &amp; I.S. (Hon.) Lond., P.G.Dip. Ind. Maths. J'Pura, MIEEE, MACM, CEO Sakrīō! ▣ *Address*: 6G • 1st Lane • Pagoda Road • Nugegoda 10250 • Sri Lanka. ▣ *Mobile* : +94-(0)711007945 ▣ *Tele*: +94-(0)11-5 864614 / 5 875614 / 2 825908 ▣ *Web *: http://www.sakrio.com ▣ This email is subjected to the email Terms of Use and Disclaimer: http://www.sakrio.com/email-legal. Please read this first. -- _______________________________________________ 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> Suminda Dharmasena 2013-05-23T12:23:55 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/62425 <pre>I have a variable length struct where an arbitrary struct will be at the end of the first one. I'm trying to find the best way to deal with this at the LLVM API level without needing to do all the alignment calculations myself. My first approach is to just put a pointer at the end of the structure, but then I can't calculate the "base" size from this structure. The other approach is to leave off this final field and then calculate the maximum alignment offset myself (it works, but doesn't take advantage of LLVM's struct calculations). Is there perhaps a way to add a maximally aligned zero-sized element to the struct? I could add this to the end and then get what I want: the size would be of the base, and the address of this final element would be the variable part. </pre> edA-qa mort-ora-y 2013-05-23T03:41:50 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/62423 <pre>Hi, I have the llvm loop vectorizer to complie the following sample: //================= int test(int *a, int n) { for(int i = 0; i &lt; n; i++) { a[i] += i; } return 0; } //================ The corresponded .ll file has a loop preheader: //================ for.body.lr.ph: ; preds = %entry %cnt.cast = zext i32 %n to i64 %0 = and i32 %n, 7 %n.mod.vf = zext i32 %0 to i64 %n.vec = sub i64 %cnt.cast, %n.mod.vf %cmp.zero = icmp eq i32 %0, %n br i1 %cmp.zero, label %middle.block, label %vector.body //================ That is , if n &lt;=7, the program will skip the vector.body. In LoopVectorize.cpp , I see the following code: //================ static cl::opt&lt;unsigned&gt; TinyTripCountVectorThreshold("vectorizer-min-trip-count", cl::init(16), ... ); //================ The minimal loop count is 16. What is the "n&lt;=7" meaning? Thanks. _______________________________________________ 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> maxs 2013-05-23T03:23:49 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/62419 <pre>Hi, I am trying to get arguments of call functions in instructions such as these: call &lt; at &gt;func(i32 %arg1, i32 %arg2). I want to get the declared variable names for arg1 and arg2. Most of these arguments are arrays, and I need to get the index of the array as well. Currently, I read arguments of the called function using getArgOperands(), and backtrace the Value* until I find an alloca instruction to get the variable name. For the array index, I backtrace until I find a getelementptr instruction. I am wondering if the information I need is captured in the metadata. I see explicit calls to llvm.dbg.value and llvm.dbg.declare when I compile with the -g option, but I can't figure out how to  retrieve the metadata for the arguments of the call&lt; at &gt;func instruction. Here is a sample LLVM IR excerpt: %a = alloca [4 x i32], align 2 %arrayidx = getelementptr inbounds i32* %a, i64 2, !dbg !42 %0 = load i32* %arrayidx, align 2, !dbg !42 call void &lt; at &gt;func(i32 %0), !dbg !42 Thank you!! Regards, shruti_______________________________________________ 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> Shruti Patil 2013-05-23T01:10:07 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/62409 <pre>Hi All, I fear starting another centi-thread on this but I'll give it a shot. We're currently supporting two build systems which is definitely one more than we (or I) want to support. I don't know of any support in autoconf past the --host/--build/--target case that's not supported in cmake. I'll send out an assertion here that this support isn't necessary and any system that needs it can instead move to: build native clang build next clang with some target that supplies a sysroot and a -target option to the native clang Can anyone see good a reason not to move to cmake as our only build configuration system and drop future support for autoconf + makefiles now that 3.3 has branched? -eric </pre> Eric Christopher 2013-05-22T23:14:06 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/62408 <pre>LLVM can model some quite complicated register banks now, and we even use registers to model some encoding constraints. For example, a few ARM instructions like strexd have two register operands that must be an aligned pair of consecutive GPR registers (like r0, r1). This constraint is modeled with the GPRPair register class containing R0_R1, R2_R3, ... pseudo-registers. Sometimes ISAs also assign assembly names to such pseudo-registers, again from ARM: SPR: (s0, s1, ...) 32-bit floating point registers. DPR: (d0, d1, ...) Even-odd pairs of consecutive S-registers. QPR: (q0, q1, ...) Even-odd pairs of consecutive D-registers. But not all constraints are given 'register' names by the ISA. One vld1 instruction variant can load two consecutive D-registers, both even-odd and odd-even pairs. An even-odd pair like {d0, d1} is also called q0, but an odd-even pair like {d1, d2} has no other ISA name. Since it's a bit random what an ISA decides to call a register and what it decides to call an encoding constraint, LLVM's concept of a physical register is usually a bit broader, but more consistent. We will normally define physical registers for all reasonable encoding constraints on register operands. For example, the LLVM ARM target has physical registers like D1_D2 which don't exist in the ISA. In a target with many encoding constraints like that, some registers can have a high number of super-registers, and even more aliases. On the last count, some of the ARM NEON registers had more than 40 aliasing registers. The register allocator uses register units to deal with the complexity of these register banks. Register units are more or less the same as leaf registers in the sub-register graph. Register interference is tracked in terms of register units, and that means it is no longer necessary to scan through the long list of aliasing registers. We still have an MCRegAliasIterator that's used here and there in the code generator, and TableGen is still emitting tables backing this iterator. I would like to minimize the use of MCRegAliasIterator because some of the alias lists are so long. In most cases, it should be possible to express algorithms in terms of register units instead. I also want to avoid emitting tables for driving MCRegAliasIterator. If required, the set of aliasing registers can be computed from regunits and super-registers. (See the block comment for MCRegUnitRootIterator or LiveIntervals::computeRegUnitInterval). /jakob </pre> Jakob Stoklund Olesen 2013-05-22T21:20:13 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/62406 <pre>Right now, I am using TargetMachine::addPassesToEmitFile &lt;http://llvm.org/docs/doxygen/html/classllvm_1_1LLVMTargetMachine.html#a356929c1f0d202e4a9d3202aff1dbb05&gt; to write the output of a backend to a file. How can I tell LLVM to write into a memory buffer instead? _______________________________________________ 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> Frank Winter 2013-05-22T20:25:31 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/62404 <pre>Anybody working on porting the compiler-rt tests to cmake? The online documentation shows a preference for cmake and ctest, but the CMakeLists file has the comment "Currently the tests have not been ported to CMake, so disable this directory." How should we be running the test suite? http://compiler-rt.llvm.org/ My immediate issue is that "make check-all" fails in the cmake build when compiler-rt is outside the projects directory. When I point to compiler-rt with LLVM_EXTERNAL_COMPILER_RT_SOURCE_DIR, lit still looks for lit.common.cfg within "projects/compiler-rt" instead of the external directory. I use similar CMake variables for Clang and Polly and have had no trouble. Any recommendations for how to fix? Thanks, Greg _______________________________________________ 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> Greg Fitzgerald 2013-05-22T19:38:43 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/62394 <pre> Hi, I downloaded latest 3.2 release of llvm and clang. used configure to generate the make files options used: ../configure --enable-debug-symbols=yes --enable-keep-symbols=yes --enable-pic=yes --enable-keep-symbols=yes --enable-debug-runtime=yes --enable-optimized=no --enable-targets=x86 --enable-embed-stdcxx=yes --enable-jit=no CXXFLAGS=-fPIC CFLAGS=-fPIC Now i get this strange error,cannot link, pls help...how to proceed. llvm[4]: Linking Debug+Asserts Shared Library libclang.so /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: /home1/ragha/llvmsrc/llvm-3.2.src/build/tools/clang/tools/libclang/Debug+Asserts/ARCMigrate.o: relocation R_X86_64_PC32 against `std::basic_string&lt;char, std::char_traits&lt;char&gt;, std::allocator&lt;char&gt; &gt;::data() const&lt; at &gt;&lt; at &gt;GLIBCXX_3.4' can not be used when making a shared object; recompile with -fPIC /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status regards ragha </pre> Raghavendra K 2013-05-22T16:06:58 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/62383 <pre>hi I am porting llvm 3.1 for a custom processor. I'm taking reference from sparc architecture. The problem I'm facing that sparc has 1 delay slot in call and conditional instructions. In my case some have 1 and some have 2 delay slots. But the backend is inserting only 1 delay slot instruction. I do not know how to insert more than 1 instruction in the delay slots. Please suggest some solution. vikram -- View this message in context: http://llvm.1065342.n5.nabble.com/Custom-delay-slot-insertion-tp57898.html Sent from the LLVM - Dev mailing list archive at Nabble.com. </pre> Vikram Singh 2013-05-22T03:58:46 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/62382 <pre>I'm battling with Xcode and Boost, so I apologize with the somewhat Xcode-specific parts of my question. I know Xcode generates Header Maps, and I've looked at clong::HeaderMap. But I don't really know how Xcode chooses to create Header Maps. I'm trying to avoid adding a search path for all of Boost, and only including the Boost headers that actually get used. Xcode seems to inconsistently find headers. One problem is that boost inconsistently uses quotes-vs.-angle brackets when including. Anyway, is there a tool that can dump out a .hmap file in human-readable form, to help me see what Xcode is doing? BTW, I've tried asking on the Xcode list for insight into how Xcode tries to use .hmaps, but have yet to receive a good answer. Thanks! </pre> Rick Mann 2013-05-22T03:51:01 http://comments.gmane.org/gmane.comp.compilers.llvm.devel/62381 <pre>I am trying to build a function (C++ Builder) and at the same time extend its parameter set. Here's what I try to do: Value* arg0 = add_param_float("arg0"); Value* tmp = builder-&gt;CreateFAdd(arg0,some_previous_value); Value* arg1 = add_param_float("arg1"); The function add_param_float should add a 'float' parameter to the function and return its value. Right now it's implemented like this Value* add_param_float() { return new llvm::Argument( llvm::Type::getFloatTy(llvm::getGlobalContext()) , param_next() , mainFunc ); } where param_next just figures some new, unused name for the argument and mainFunc is the function being built. This works to a certain extent. I am seeing issues with certain type printers and I assume the way the argument is added to the function is not a strictly valid thing to do. I guess one cannot change the function type once it's created. (Then maybe the constructor of Argument should not be public). However, in my setup I need to add new arguments to the function. What would be the best way to do it? I was thinking of implementing a new function like CloneFunction which takes an additional argument that can be added to it. But, is this really necessary? Isn't there a simpler, more straight-forward way to do this? Any help/thoughts is appreciated! Frank </pre> Frank Winter 2013-05-22T00:27:29 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.compilers.llvm.devel