search for: targetdata

On Wed, Oct 21, 2009 at 10:59 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > If the TargetData pass isn't registered in the global registry, > getPassInfo() returns null. > > Now when you add a TargetData pass, it winds up in ImmutablePasses. > Any search through ImmutablePasses assumes that getPassInfo() for > every member returns something other than null.  So findAnalys...

...quot;modpass1", ""); RegisterPass<FunPass1> B("funpass1", ""); RegisterPass<ModPass2> C("modpass2", ""); int main(int argc, char argv) { PassManager PM; PM.add(new ModPass2); } ****** Also of note, if the first module requires TargetData, then the code will fail earlier with the assertion [include/llvm/Target/TargetData.h:114: llvm::TargetData::TargetData(): Assertion `0 && "ERROR : Bad TargetData ctor used. " "Tool did not specify a TargetData to use?"' failed]. This occurs even when a valid Target...

...none", "host", or a target string.  If -defaulttarget is not >> specified, the behavior of "opt" will be the same as it is presently. >> The defaulttarget will be overridden by the Module's target data if it >> has some.  "none" means that no TargetData pass will be added unless >> the Module supplies target data.  "host" uses the running host's >> TargetData as the default. >> >> What do y'all think? > > I think it's more intuitive to have command-line information override > Module informatio...

...Infoin libLLVMEBCCodeGen.a(EBCRegisterInfo.cpp.o) vtable for llvm::EBCGenRegisterInfoin libLLVMEBCCodeGen.a(EBCRegisterInfo.cpp.o) "llvm::TargetMachine::getAsmVerbosityDefault()", referenced from: getVerboseAsm() in libLLVMCodeGen.a(LLVMTargetMachine.cpp.o) "llvm::TargetData::getPrefTypeAlignment(llvm::Type const*) const", referenced from: llvm::SelectionDAG::getConstantPool(llvm::MachineConstantPoolValue*, llvm::EVT, unsigned int, int, bool, unsigned char)in libLLVMSelectionDAG.a(SelectionDAG.cpp.o) llvm::SelectionDAG::getConstantPool(llvm::Constant c...

...&PI) { bool Inserted = PassInfoMap.insert(std::make_pair(PI.getTypeInfo(),&PI)).second; assert(Inserted && "Pass registered multiple times!"); } i confirm that there is only one static variable suspecting to call this register routine to register "TargetData" Pass in L35 [TargetData.cpp] // Register the default SparcV9 implementation... static RegisterPass<TargetData> X("targetdata", "Target DataLayout", false, true); but back track things before main entry, i got actually twice same intializations: the attached is...

...ink it would make sense to make these relationships backend/platform > specific, but for clang and the optimization passes to properly work with > address spaces, these relationships should be known. It seems to me that the > proper way to handle this, is to include this information in the TargetData > class (or whatever platform-specific class is appropriate, I'm not really into > this currently). To have something to actually talk about, I thought I'd create some code. I've got a patch attached which consists roughly of two parts: it adds the concept of address space relati...

On Oct 21, 2009, at 9:31 AM, Kenneth Uildriks wrote: > On Wed, Oct 21, 2009 at 10:59 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: >> If the TargetData pass isn't registered in the global registry, >> getPassInfo() returns null. >> >> Now when you add a TargetData pass, it winds up in ImmutablePasses. >> Any search through ImmutablePasses assumes that getPassInfo() for >> every member returns something other than...

...Infoin libLLVMEBCCodeGen.a(EBCRegisterInfo.cpp.o) vtable for llvm::EBCGenRegisterInfoin libLLVMEBCCodeGen.a(EBCRegisterInfo.cpp.o) "llvm::TargetMachine::getAsmVerbosityDefault()", referenced from: getVerboseAsm() in libLLVMCodeGen.a(LLVMTargetMachine.cpp.o) "llvm::TargetData::getPrefTypeAlignment(llvm::Type const*) const", referenced from: llvm::SelectionDAG::getConstantPool(llvm::MachineConstantPoolValue*, llvm::EVT, unsigned int, int, bool, unsigned char)in libLLVMSelectionDAG.a(SelectionDAG.cpp.o) llvm::SelectionDAG::getConstantPool(llvm::Constant c...

Dear all I am trying to get the size of an LLVM pointer type. getPrimitiveSizeInBits() returns 0 for it and the documentation for isSized() suggest to use TargetData. I figured out from Kaleidoscope example that one can get a pointer to TagetData object through the execution engine but it seems to be an overkill. What is the right way to do it? Best regards, Victor -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists...

I am using opt , so i cm confused if i need to do this. On the other hand I modified my functionPass not to call TargetData , and I still get this error. My functionPass still calls Alias Analysis though. Aparna On Fri, Aug 13, 2010 at 2:15 PM, John Criswell <criswell at illinois.edu>wrote: > aparna kotha wrote: > >> All, >> I have a ModulePass (A) calling a FunctionPass that inturn calls &g...

...gives error I want to report a bug but i don't know if this is a real bug or i am doing something wrong, knowing that i am adding other function passe to my module pass and it works fine. the error i get: adding callgraph pass ... done opt: /net/home/yehia/llvm/llvm-2.4/include/llvm/Target/TargetData.h:114: llvm::TargetData::TargetData(): Assertion `0 && "ERROR: Bad TargetData ctor used. " "Tool did not specify a TargetData to use?"' failed. adding DependenceFlowGraph_FunctionAnalaysis_Pass ... doneopt[0x75627f] /lib64/libc.so.6[0x3880a30070] /lib64/libc.so.6(...

If the TargetData pass isn't registered in the global registry, getPassInfo() returns null. Now when you add a TargetData pass, it winds up in ImmutablePasses. Any search through ImmutablePasses assumes that getPassInfo() for every member returns something other than null. So findAnalysisPass for *any* analysi...

...gt;> Unfortunately, yes.  See PR4542.  Progress has been made recently >>> though -- the optimizers are now ready.  The main things left to do >>> is to update the documentation and update the testsuite to account >>> for the change in the meaning of a module without a targetdata string. >>> >>> Dan >>> >>> >> >> So in the near future, the optimizers won't do any target-specific >> transformations in the absence of module target data? > > As near as when someone steps up to do the work :-). I'm not > act...

...In terms of the information we need, I think you have it right. We just need a description of how the different address spaces relate and I don't see much of an issue with how you implemented to InstructionCombining. As you also mentioned, I don't like that we pass a reference to TargetData with the AddrspacesDescriptor and that we have a static default implementation store in the class. It is unclear to me if this is the right class for it as not as it describes the structure and alignment while address spaces seems distinct from that. I feel that this information should be...

actually i only created a new Module pass and tried to getAnalysis of MemoryDependenceAnalysis from it, i didn't use TargetData directly to regenerate the error i am attaching a c file containing an example code to regenerate the error. with its Makefile the command line i used is: opt -time-passes -analyze -load ${LLVM_PATH}/Release/lib/.libs/libMYMODULEPASS.so -MyModulePass < test.bc i tried the same but from a fun...

...driks <kennethuil at gmail.com> wrote: >> I think it's more intuitive to have command-line information override >> Module information. That's how llc works, for example. >> >> Also, is the argument to -defaulttarget a triple, an architecture name, >> or a targetdata string? If it's a triple, it'd be nice to be consistent >> with llc and call it -mtriple=. For an architecture name, -march=. >> If it's a targetdata string, perhaps -targetdata= would be a good name. >> >> (As an aside, I wouldn't object to having llc's...

...terPass<FunPass1> B("funpass1", ""); > RegisterPass<ModPass2> C("modpass2", ""); > > int main(int argc, char argv) { > PassManager PM; > PM.add(new ModPass2); > } > ****** > > Also of note, if the first module requires TargetData, then the code > will fail earlier with the assertion > [include/llvm/Target/TargetData.h:114: llvm::TargetData::TargetData(): > Assertion `0 && "ERROR > : Bad TargetData ctor used. " "Tool did not specify a TargetData to > use?"' failed]. This occurs...

All, I have a ModulePass (A) calling a FunctionPass that inturn calls TargetData (a ModulePass). For reasons of code correctness and modularity I cannot reorganize my passes in any other way . When I use opt to load and run A , it gives the following error. LLVM ERROR: Bad TargetData ctor used. Tool did not specify a TargetData to use? I gather from some previous emails th...

Victor Zverovich wrote: > Dear all > > I am trying to get the size of an LLVM pointer type. > getPrimitiveSizeInBits() returns 0 for it and the documentation for > isSized() suggest to use TargetData. > I figured out from Kaleidoscope example that one can get a pointer to > TagetData object through the execution engine but it seems to be an > overkill. > What is the right way to do it? TargetData is an LLVM pass. If you're writing an LLVM pass, just make TargetData one of it...

...d > MemoryDependenceAnalysis it gives error > I'm going to assume that you're running your passes via a specially built tool and not as a set of passes loaded into the opt program. If this assumption is wrong, please let me know. Looking at the assertion, you're creating a TargetData pass without passing in either a string describing the target or an LLVM Module * from which TargetData can look up the relevant architecture information. For example, in the hand-written SAFECode tool, the following code should cause the same error: PassManager Passes; Passes.add (new TargetD...