similar to: [LLVMdev] Ideas for making llvm-config --cxxflags more useful

Displaying 20 results from an estimated 7000 matches similar to: "[LLVMdev] Ideas for making llvm-config --cxxflags more useful"

2015 Aug 07
2
[LLVMdev] Ideas for making llvm-config --cxxflags more useful
On Fri, Aug 7, 2015 at 10:22 AM, Hans Wennborg via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Aug 6, 2015 at 12:04 PM, David Chisnall via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > [Ooops, sent to the old list address by mistake] > > > > On 30 Jul 2015, at 21:04, tom at stellard.net wrote: > >> > >> For flags like
2015 Aug 07
3
[LLVMdev] Ideas for making llvm-config --cxxflags more useful
I’ve almost finished a patch to add back in either out of line destructors or anchor methods. We seem to use one or the one, relatively inconsistently. What i’ve gone for is that if a class already had an inline destructor then i left it alone and added an anchor method. Otherwise I added an out of line destructor. Now if I compile Instructions.cpp with -Wweak-vtable, the only warnings given
2015 Aug 07
2
[LLVMdev] Ideas for making llvm-config --cxxflags more useful
> On Aug 7, 2015, at 12:32 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Fri, Aug 7, 2015 at 11:30 AM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote: > I’ve almost finished a patch to add back in either out of line destructors or anchor methods. We seem to use one or the one, relatively inconsistently. >
2017 Apr 14
5
Saving Compile Time in InstCombine
I’m taking a first look at InstCombine performance. I picked up the caching patch and ran a few experiments on one of our larger C++ apps. The size of the *.0.2.internalize.bc no-debug IR is ~ 30M. Here are my observations so far. Interestingly, caching produced a slight but measurable performance degradation of -O3 compile time. InstCombine takes about 35% of total execution time, of which ~20%
2013 Jan 15
2
[LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments
On Wed, Dec 12, 2012 at 01:59:55PM -0800, Dan Gohman wrote: > The bug here isn't in clang's use of noalias or in BasicAliasAnalysis' > implementation of noalias; it's in the code that's optimizing the > icmp. Let's come back to this. The attached patch decouples InstSimplify from the alias analysis and provides the conservative logic for when pointers are not
2017 May 23
3
Removing "fno-rtti" flag from llvm-config --cxxflags
Hi everyone, I just had a question - I am aware that LLVM supports it's own form of RTTI ( using dyn_cast<>() ,etc) but I wish to use C++ RTTI currently. I have tried building with "cmake -G "Unix Makefiles" -LLVM_ENABLE_RTTI=ON" but that doesnt seem to remove the "fno-rtti" flag from llvm-config and I still get an error when I try using
2010 Jul 27
1
[LLVMdev] How to use the return value of a CallInst
Hi all: I am trying to compare the return value of a call instruction with 0. The called function's return type is uint32. The return value is 1 or 0. But the icmp instruction cannot be created. CallInst *ret = CallInst::Create(ptr_func, params.begin(), params.end(), "", bb); Value *cmp = new ICmpInst(*bb, ICmpInst::ICMP_EQ, ret, ,ConstantInt::get(getIntegerType(32), 0)
2016 Feb 19
3
undefined reference to typeinfo for CmpInst
Hi all, I am having some some trouble with LLVM 3.8... I built it with GCC 4.8.2 with cmake and no special CXX/C flags. That means in case of GCC that RTTI is switched on, I believe. However, building my MCJIT application against the just built LLVM and linking results in: libqdp.a(qdp_llvm.o):(.rodata._ZTIN4llvm8FCmpInstE[_ZTIN4llvm8FCmpInstE]+0x10): undefined reference to `typeinfo for
2015 Jul 30
2
[LLVMdev] Ideas for making llvm-config --cxxflags more useful
Hi, My understanding of llvm-config --cxxflags is that it is supposed to report which flags are necessary to compile a program that will include LLVM's headers and link against its libraries. What it currently reports is all of the flags which were used to compile LLVM. This is not very useful, because users are required in most cases to filter out flags they don't want. I would like
2012 Dec 12
0
[LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments
On Wed, Dec 12, 2012 at 1:26 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Wed, Dec 12, 2012 at 11:01:01AM -0800, Dan Gohman wrote: >> > Is that >> > assumption violated if I explicitly cast away const and pass the result >> > to a function with NoAlias argument? >> >> Not immediately, no. It means that you can't access the
2015 Aug 08
2
[LLVMdev] Ideas for making llvm-config --cxxflags more useful
On 7 Aug 2015, at 23:17, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I don't have any strong opinions. Did this actually break anyone's use > case or is it just a hypothetical problem? It doesn't seem like there > is much value in fixing this until llvm-config is also fixed. The current 3.7 code breaks for the codebase that I use for
2012 Dec 12
3
[LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments
On Wed, Dec 12, 2012 at 11:01:01AM -0800, Dan Gohman wrote: > > Is that > > assumption violated if I explicitly cast away const and pass the result > > to a function with NoAlias argument? > > Not immediately, no. It means that you can't access the constant > pointer's pointee directly within the noalias argument's scope. Access > to that object must go
2016 Feb 16
4
[help] Kaleidoscope build fails after llvm-3.8
Hello , I have build llvm from release_38 branch ( only llvm and clang ) and install it. My DYLD_LIBRARY_PATH points to installation-directory/lib. I am compiling example files for Kaleidoscope with following command : clang++ -g toy.cpp -std=c++11 `llvm-config --cxxflags --ldflags --system-libs --libs core mcjit native` -O3 -o toy but it fails with following error: Undefined symbols for
2011 Sep 19
2
[LLVMdev] copy Value object?
Sorry, I'm a bit confused by your reply. I think part of my problem is I can only think of this in terms of Passes. For instance, my pass looks for assignments and tries to use the same pointer operand, before the assignment it finds. Like this: new ICmpInst(*block, CmpInst::ICMP_NE, shadow, store->getPointerOperand(), "Shadow check"); So I'm not sure how alloca
2015 Aug 03
8
[LLVMdev] Ideas for making llvm-config --cxxflags more useful
> On Aug 3, 2015, at 10:24 AM, Chris Bieneman <beanz at apple.com> wrote: > > Hey Tom, > > I’m not a regular user of llvm-config, but this sounds completely right to me, and it would be a significant improvement over what we have now. > > The only question I want to raise is, what about NDEBUG? There are headers that conditionalize on NDEBUG, which could lead to ABI
2011 Sep 28
3
[LLVMdev] ICmpInst example?
I'm trying to come up with a simple example of using ICmpInst in a Pass. On each of the branches(true, false) I'd like to call a separate function and then resume(to the code that was already there). In this example i is a inst_iterator to Instruction the Pass is currently on. Now it segfaults opt before I can even get a dump() on it. Does anyone see what I am doing wrong? BasicBlock
2011 Oct 12
2
[LLVMdev] insert ICmpInst/BranchIns in Pass?
In a pass I would like to insert a ICmpInst/BranchInst pair to check if 2 GlobalVariables are equal or not. If they are not I would like to call a function. I've tried splitting the current block and then inserting before the existing instructions, but for some reason this seems to ruin the iterator(i). What is the correct way todo something like this? void checkShadowPtr(Module &M,
2010 Mar 14
2
[LLVMdev] Why does `llvm-config --cxxflags` now include -fno-rtti ?
Hi, I'm trying to port a piece of code using LLVM as a library to the latest SVN version. One difference between 2.6 and 2.7svn is that `llvm-config --cxxflags` now include -fno-rtti. Since my code does use RTTI information (in non-trivial dynamic_cast), my code can't compile with this. Same goes for -fexceptions. I've tried setting my CXXFLAGS to `llvm-config --cxxflags` -frtti
2012 Nov 23
0
[LLVMdev] llvm-config --cxxflags is not consistent when building by cmake.
Duncan Sands <baldrick at free.fr> writes: >> Using -fno-rtti and -fno-exceptions is an internal LLVM policy. There is >> no reason to impose it on client code. > > actually it does impact external code. For example dragonegg does > > #include "llvm/Support/PluginLoader.h" > > This file contains > > // This causes operator= above to be
2012 Nov 21
2
[LLVMdev] llvm-config --cxxflags is not consistent when building by cmake.
Hi, We found `llvm-config --cxxflags' does not have -fno-exceptions -fno-rtti when using cmake to build LLVM. Does anyone know how to fix it? Best regards, Luba ---------- Forwarded message ---------- From: Luba Tang <lubatang at gmail.com> Date: 2012/11/21 Subject: Re: [MCLinker] Re: Major release - MCLinker 2.0.0 - RockBull To: mclinker at googlegroups.com Hi, We make sure the