search for: transformutils

...led,color=olivedrab1]; X86Info [shape=box,style=filled,color=olivedrab1]; X86Disassembler [shape=box,style=filled,color=olivedrab1]; X86CodeGen [shape=box,style=filled,color=olivedrab1]; X86AsmPrinter [shape=box,style=filled,color=olivedrab1]; X86AsmParser [shape=box,style=filled,color=olivedrab1]; TransformUtils [shape=box,style=filled,color=olivedrab1]; Target [shape=box,style=filled,color=olivedrab1]; System [shape=box,style=filled,color=olivedrab1]; Support [shape=box,style=filled,color=olivedrab1]; SelectionDAG [shape=box,style=filled,color=olivedrab1]; ScalarOpts [shape=box,style=filled,color=olivedra...

Hello, I have a question about how to set up a Makefile that generate a .so that I can load into opt without getting duplicate symbols. Here's what I have right now: LIBRARYNAME=previrt SHARED_LIBRARY=previrt LINK_COMPONENTS := transformUtils LINK_LIBS_IN_SHARED=1 include $(LEVEL)/Makefile.common LIBS += -lprotobuf CPPFLAGS += -I${HOME}/.root/usr/include -DGOOGLE_PROTOBUF_NO_RTTI LDFLAGS += -Wl,-L${HOME}/.root/usr/lib/ PROTOC=${HOME}/.root/usr/bin/protoc I'm pretty sure the problem comes from LINK_LIBS_IN_SHARED, but my code dep...

...ve a question about how to set up a Makefile that generate a .so that I > can load into opt without getting duplicate symbols. Here's what I have > right now: > > > Have you tried removing LINK_COMPONENTS below? I suspect that the opt > binary already contains everying in the transformUtils library. > > -- John T. > > > LIBRARYNAME=previrt > SHARED_LIBRARY=previrt > LINK_COMPONENTS := transformUtils > LINK_LIBS_IN_SHARED=1 > > include $(LEVEL)/Makefile.common > > LIBS += -lprotobuf > > CPPFLAGS += -I${HOME}/.root/usr/include -DGOOGLE_PROTOBUF_...

..., > > I have a question about how to set up a Makefile that generate a .so > that I can load into opt without getting duplicate symbols. Here's > what I have right now: Have you tried removing LINK_COMPONENTS below? I suspect that the opt binary already contains everying in the transformUtils library. -- John T. > > LIBRARYNAME=previrt > SHARED_LIBRARY=previrt > LINK_COMPONENTS := transformUtils > LINK_LIBS_IN_SHARED=1 > > include $(LEVEL)/Makefile.common > > LIBS += -lprotobuf > > CPPFLAGS += -I${HOME}/.root/usr/include -DGOOGLE_PROTOBUF_NO_RTTI >...

...bout how to set up a Makefile that generate a .so that >> I can load into opt without getting duplicate symbols. Here's what I have >> right now: >> >> Have you tried removing LINK_COMPONENTS below?  I suspect that the opt >> binary already contains everying in the transformUtils library. >> >> -- John T. >> >> >> LIBRARYNAME=previrt >> SHARED_LIBRARY=previrt >> LINK_COMPONENTS := transformUtils >> LINK_LIBS_IN_SHARED=1 >> >> include $(LEVEL)/Makefile.common >> >> LIBS += -lprotobuf >> >> CP...

Hi, After r256521 - which removes InlineCostAnalysis class - I think there is no strong reason for InlineCost.cpp to be part of the Analysis library. Is it fine to make it part of TransformUtils? I submitted r266477 (which has now been reverted) that made Analysis depend on ProfileData in order to obtain ProfileSummary for the module, but there is an existing dependency of ProfileData on Analysis (through Object and BitCode). Moving InlineCost.cpp under Transforms/Utils will fix this issu...

...1] (and related code [0]) there. This Builder translates "OpenMP directives" to LLVM-IR and is supposed to be reused in Flang. First, I tried to place the OpenMP-IR-Builder into llvm/IR, right next to the llvm::IRBuilder, but it would soon introduce a dependence on other libraries (first TransformUtils) [2]. There are more things (especially parts of Clang) that could arguably be shared across frontends and therefore be moved into a such a dedicated location. If it turns out this is a controversial RFC, we will provide examples and reasons. I hope this is fairly straightforward as this does not...

...bject: Move InlineCost.cpp out of Analysis? >> >> >> Hi, >> >> >> After r256521 - which removes InlineCostAnalysis class - I think >> there is no strong reason for InlineCost.cpp to be part of the >> Analysis library. Is it fine to make it part of TransformUtils? >> > > Given that InlineCost is not really an analysis any longer, I think this is fine. Isn't it? It is not a pass, but I see it as an analysis utils. > >> >> I submitted r266477 (which has now been reverted) that made Analysis >> depend on ProfileData i...

...t; >> >> >> Hi, >> >> >> >> >> >> After r256521 - which removes InlineCostAnalysis class - I think >> >> there is no strong reason for InlineCost.cpp to be part of the >> >> Analysis library. Is it fine to make it part of TransformUtils? >> >> >> > >> > Given that InlineCost is not really an analysis any longer, I think >> this is fine. >> >> Isn't it? It is not a pass, but I see it as an analysis utils. >> >> > >> >> >> >> I submitted r2664...

...slates "OpenMP directives" to LLVM-IR > > and is supposed to be reused in Flang. > > > > First, I tried to place the OpenMP-IR-Builder into llvm/IR, right next > > to the llvm::IRBuilder, but it would soon introduce a dependence on > > other libraries (first TransformUtils) [2]. > > I think it is a great idea to share the OpenMP lowering code, but I’m > concerned about the name 'lib/Frontend’. This is a very broad name > and there are lots of things that “could be useful for frontends” - > and a lot of definitions of what a “frontend" is. F...

...d utility? > > > In the current case at stake: the issue is that we can't make the Analysis > library using anything from the ProfileData library. Conceptually there is > a problem IMO. > Yes -- this is a very good point. David > > Moving something from Analysis to TransformUtils just because it needs to > access ProfileData is a slippery slope... > > -- > Mehdi > > > > David > > > >> >> On Mon, Apr 18, 2016 at 2:14 PM Mehdi Amini via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> >>>...

...MemoryID) LLVMIA64.o: libLLVMCodeGen.a(vtable for llvm::DefaultIntrinsicLowering) libLLVMTarget.a: libLLVMCodeGen.a( llvm::MVT::getVectorType(llvm::MVT::ValueType, unsigned int)) The following dependencies is not a singleton, but they it just seemed dubious to me that "TransformUtils" would depend on ScalarOpts. libLLVMTransformUtils.a: libLLVMScalarOpts.a llvm::LowerSelectID llvm::LowerSwitchID llvm::PromoteMemoryToRegisterID Something else that came up fairly often. Several libraries depend on libLLVMTarget.a solely to get at the TargetData class. Perhaps this sh...

...VMBuild.txt is as minimal as I could guess at: [common] subdirectories = [component_0] type = TargetGroup name = TMS9900 parent = Target [component_1] type = Library name = TMS9900CodeGen parent = TMS9900 required_libraries = Analysis AsmPrinter CodeGen Core MC Scalar SelectionDAG Support Target TransformUtils add_to_library_groups = TMS9900 And finally, TMS9900.td contains: include "llvm/Target/Target.td" def TMS9900 : Target { } I also updated lib/Target/LLVMBuild.txt's [common] subdirectories to include TMS9900. *The punchline:* Now, I tried to run cmake: $ cd build $ cmake -G &quo...

...iews.llvm.org/D25364 we were discussing possibility of verifying LCSSA only for the top-level loops. I started implementing this but process appears to be a bit tricky. Problem is that I can’t find a way to check that LPPassManager contains LCSSA pass without introducing circular dependency between TransformUtils and Analysis libraries. I have couple of solutions in mind but wanted to ask your opinion on those, maybe we will be able to arrive at better decision. >> >> 1. I can introduce list of loops which LCSSAWrapperPass::verifyAnalysis needs to verify. It will be stored in the LoopInfo and p...

...iews.llvm.org/D25364 we were discussing possibility of verifying LCSSA only for the top-level loops. I started implementing this but process appears to be a bit tricky. Problem is that I can’t find a way to check that LPPassManager contains LCSSA pass without introducing circular dependency between TransformUtils and Analysis libraries. I have couple of solutions in mind but wanted to ask your opinion on those, maybe we will be able to arrive at better decision. 1. I can introduce list of loops which LCSSAWrapperPass::verifyAnalysis needs to verify. It will be stored in the LoopInfo and populated in the LP...

...iews.llvm.org/D25364 we were discussing possibility of verifying LCSSA only for the top-level loops. I started implementing this but process appears to be a bit tricky. Problem is that I can’t find a way to check that LPPassManager contains LCSSA pass without introducing circular dependency between TransformUtils and Analysis libraries. I have couple of solutions in mind but wanted to ask your opinion on those, maybe we will be able to arrive at better decision. >>>> >>>> 1. I can introduce list of loops which LCSSAWrapperPass::verifyAnalysis needs to verify. It will be stored in th...

...ct: Re: [LLVMdev] diffs for vc7.1 >Date: Tue, 14 Sep 2004 11:13:10 +0200 > >Hi all, > >Attached to this email you can find the diffs versus current CVS that makes >all the touched files compile under Microsoft Visual C 7.1 > >The following libs are now building: >vmcore, transformutils, transform, cwriter, lli-jit, executionengine, >selectiondag, modulosched, sched, bcwriter, datastructure, ipa > >Next patch will be the conversion of some C99 dynamic array to std::vector, >if nobody complains about it... ><< diff.txt >> > >--- >Paolo Inverniz...

...r translates "OpenMP directives" to LLVM-IR >> and is supposed to be reused in Flang. >> >> First, I tried to place the OpenMP-IR-Builder into llvm/IR, right next >> to the llvm::IRBuilder, but it would soon introduce a dependence on >> other libraries (first TransformUtils) [2]. >> >> There are more things (especially parts of Clang) that could arguably be >> shared across frontends and therefore be moved into a such a dedicated >> location. If it turns out this is a controversial RFC, we will provide >> examples and reasons. >> &g...

...txt: ``` set(LLVM_LINK_COMPONENTS ${LLVM_TARGETS_TO_BUILD} AggressiveInstCombine Analysis BitWriter CodeGen Core MC MCJIT Object OrcJIT Interpreter RuntimeDyld Coroutines IPO IRReader InstCombine Instrumentation MC ObjCARCOpts ScalarOpts Support Target TransformUtils Vectorize Passes ExecutionEngine ) # Support plugins. set(LLVM_NO_DEAD_STRIP 1) add_llvm_tool(opt AnalysisWrappers.cpp BreakpointPrinter.cpp Debugify.cpp GraphPrinters.cpp NewPMDriver.cpp PassPrinters.cpp PrintSCC.cpp opt.cpp DEPENDS intrinsics_gen ) export_executab...

On Fri, 3 Sep 2004, Paolo Invernizzi wrote: > I can confirm that both are compiled properly: Ok. > for (BasicBlock::iterator I = H->begin; isa<PHINode>(I); I++) { > PHINode *PN = cast<PHINode(I); > .... > } > > I'll make a patch for whatever solution do you prefer (this problem is > a showstopper for more than a dozen files...) I prefer this