search for: targetinstrinfoimpl

...tner at apple.com> wrote: > On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? >> >> TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen to not depend on libCodeGen, but I don't think they serve any purpose as part of libTarget. >> >> Similarly, the functions in lib/Target/TargetRegisterInfo....

Hi, Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen to not depend on libCodeGen, but I don't think they serve any purpose as part of libTarget. Similarly, the functions in lib/Target/TargetRegisterInfo.cpp happen to not...

...etData::getABIIntegerTypeAlignment(unsigned int) const", referenced from: llvm::MachineJumpTableInfo::getEntryAlignment(llvm::TargetData const&) constin libLLVMCodeGen.a(MachineFunction.cpp.o) "typeinfo for llvm::TargetInstrInfo", referenced from: typeinfo for llvm::TargetInstrInfoImplin libLLVMCodeGen.a(TargetInstrInfoImpl.cpp.o) "llvm::TargetMachine::TargetMachine(llvm::Target const&)", referenced from: llvm::LLVMTargetMachine::LLVMTargetMachine(llvm::Target const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> &gt...

...wrote: > >> On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >>> Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? >>> >>> TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen to not depend on libCodeGen, but I don't think they serve any purpose as part of libTarget. >>> >>> Similarly, the functions in lib/Target/TargetRegis...

On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? > > TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen to not depend on libCodeGen, but I don't think they serve any purpose as part of libTarget. > > Similarly, the functions in lib/Target/TargetRegisterInfo.cpp happ...

I found myself wanting a "scheduling barrier" in LLVM. In my specific circumstances I only want it to mean that TargetInstrInfoImpl::isSchedulingBoundary() would return true. I added SchedulingBarrier to MCID in MCInstrDesc.h and pushed it through TD attributes down to isSchedulingBoundary(). Is this something of general interest, or is there another mechanism for implementing barriers that I missed? Thanks --------------...

...allocator and to all the existing machinery, is usually very short. All I need is that the spilling code would be never inserted into a live range of the FLAGS register. Is this possible? (As a side note: I tried to work-around the problem by moving the spilling code around "by hand" in TargetInstrInfoImpl::loadRegFromStackSlot / storeRegToStackSlot, but that is too late because physical registers are already allocated by then and thus it is not always possible to move the spilling code around without disturbing other register data dependencies.) Thanks, Jara -- Space--the final frontier!

...I might be able to figure out how to prevent it from being overzealous. Second, I tried putting the code you gave in my app, and I got into a wild goose chase of include files not being found. Finally ended with: <myabsolutepathroot>\llvm\target\x86\x86instrinfo.h(225) : error C2504: 'TargetInstrInfoImpl' : base class undefined Did you put that code into LLVM itself and then call it from your app? Lastly, what do you mean by "somewhere real"? Thanks again, Aaron > You'll need to link in x86.lib as generated from the VStudio project. > > I had trouble convincing V...

...e out target-independent pieces into CodeGen, it also introduces some confusion where the default implementation is in CodeGen while target overridden version are in Target. I also hate to see all these Target* classes being moved to CodeGen. I thought our solution to this issue is classes such as TargetInstrInfoImpl. What's wrong with it? Evan On Dec 10, 2011, at 7:25 PM, Nick Lewycky wrote: > Nick Lewycky wrote: >> We've had a circular dependency in LLVM for a while, and while we've >> been fortunate that we could ignore it by implementing functions in >> header files, a re...

...get-independent pieces into CodeGen, it also introduces some confusion where the default implementation is in CodeGen while target overridden version are in Target. I also hate to see all these Target* classes being moved to CodeGen. > > I thought our solution to this issue is classes such as TargetInstrInfoImpl. What's wrong with it? I wasn't familiar with TargetFooImpl when I sent out the initial mail. I don't like it because it splits the implementation of the class across two entirely separate libraries (not merely source files), it's easy to accidentally regress the dependency, it doe...

...I might be able to figure out how to prevent it from being overzealous. Second, I tried putting the code you gave in my app, and I got into a wild goose chase of include files not being found. Finally ended with: <myabsolutepathroot>\llvm\target\x86\x86instrinfo.h(225) : error C2504: 'TargetInstrInfoImpl' : base class undefined Did you put that code into LLVM itself and then call it from your app? Lastly, what do you mean by "somewhere real"? Thanks again, Aaron > You'll need to link in x86.lib as generated from the VStudio project. > > I had trouble convincing V...

...const > = 0; > + > }; Great! But perhaps change the name to GetInstSizeInBytes() to be more explicit? Same for GetFunctionSize(). Hrm. Are there machines where instructions may not be byte sized? I guess we'll worry about it if someone adds that target. :-) > > > /// TargetInstrInfoImpl - This is the default implementation of > @@ -408,6 +420,7 @@ > MachineBasicBlock::iterator MI, > unsigned DestReg, > const MachineInstr *Orig) const; > + virtual unsigned GetFunctionSize(const Ma...

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And

Nick Lewycky wrote: > We've had a circular dependency in LLVM for a while, and while we've > been fortunate that we could ignore it by implementing functions in > header files, a recent innocent change caused a cyclic dependency > between Target and CodeGen just because of inlining that happens in > GCC. I'm proposing to fix this by moving code from Target to CodeGen

We've had a circular dependency in LLVM for a while, and while we've been fortunate that we could ignore it by implementing functions in header files, a recent innocent change caused a cyclic dependency between Target and CodeGen just because of inlining that happens in GCC. I'm proposing to fix this by moving code from Target to CodeGen If I understand correctly, lib/CodeGen is

...ibLLVMAVRCodeGen.a(AVRTargetMachine.cpp.o): In function `~AVRGenRegisterInfo': /home/john/src/llvm_build/lib/Target/AVR/AVRGenRegisterInfo.h.inc:14: undefined reference to `llvm::TargetRegisterInfo::~TargetRegisterInfo()' ../../lib/libLLVMAVRCodeGen.a(AVRTargetMachine.cpp.o): In function `~TargetInstrInfoImpl': /home/john/src/llvm2.6/include/llvm/Target/TargetInstrInfo.h:474: undefined reference to `llvm::TargetInstrInfo::~TargetInstrInfo()' ../../lib/libLLVMAVRCodeGen.a(AVRTargetMachine.cpp.o): In function `~AVRSubtarget': /home/john/src/llvm2.6/lib/Target/AVR/AVRSubtarget.h:24: undefined...