search for: targetelfwriterinfo

Perhaps it could have been removed when ELFWriter was removed in r147615? http://llvm.org/viewvc/llvm-project?view=rev&revision=147615 - Jan On Fri, Oct 26, 2012 at 4:41 PM, Jan Voung <jvoung at chromium.org> wrote: > Oops, sorry hit send too early -- meant to just make a draft email. I'm > still looking through, but so far I hadn't seen many of its methods being >

Hi Jan, Why do you think TargetELFWriterInfo is not used (IIUC)? I see a lot of targets inherit class TargetELFWriterInfo for their ELF writer. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chen...

On Fri, Oct 26, 2012 at 6:01 PM, 陳韋任 (Wei-Ren Chen) < chenwj at iis.sinica.edu.tw> wrote: > Hi Jan, > > Why do you think TargetELFWriterInfo is not used (IIUC)? > I see a lot of targets inherit class TargetELFWriterInfo > for their ELF writer. > > Yes, a lot of targets inherit it, but it looks like nothing ever calls getELFWriterInfo() (anymore) to get access to the instances. > Regards, > chenwj > > -- > W...

2012/10/27 Jan Voung <jvoung at chromium.org>: > On Fri, Oct 26, 2012 at 6:01 PM, ��f�� (Wei-Ren Chen) > <chenwj at iis.sinica.edu.tw> wrote: >> >> Hi Jan, >> >> Why do you think TargetELFWriterInfo is not used (IIUC)? >> I see a lot of targets inherit class TargetELFWriterInfo >> for their ELF writer. >> > > Yes, a lot of targets inherit it, but it looks like nothing ever > calls getELFWriterInfo() (anymore) to get access to the instances. > Via greping, I find...

<br>

Oops, sorry hit send too early -- meant to just make a draft email. I'm still looking through, but so far I hadn't seen many of its methods being used... On Fri, Oct 26, 2012 at 4:37 PM, Jan Voung <jvoung at chromium.org> wrote: > > -------------- next part -------------- An HTML attachment was scrubbed... URL:

but some target like sparc still depends on those codes... 2012/10/30 ��f�� (Wei-Ren Chen) <chenwj at iis.sinica.edu.tw>: >> In consideration of those codes in XXXAsmPrinter class which print out >> MachineInstr in .s format, I tend to think they are old codes that >> might be obsolete and will be replaced with MC layer implementation, >> but I am not sure. > >

> In consideration of those codes in XXXAsmPrinter class which print out > MachineInstr in .s format, I tend to think they are old codes that > might be obsolete and will be replaced with MC layer implementation, > but I am not sure. How about sending a patch which remove those obsolete code, and let others give comment? Cheers, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab,

...s the > right thing to do, and meanwhile I'm going to try to prepare a patch > that does this. I've gone ahead and done this. With the attached patch applied, nothing in lib/Target/* or include/llvm/Target/* include anything from include/llvm/CodeGen. The .cpp files that moved are TargetELFWriterInfo, TargetFrameLowering, TargetLoweringObjectFile, TargetMachine, TargetOptions, TargetRegisterInfo and TargetSubtargetInfo. The .h files that moved are the matching headers for the .cpp files plus TargetInstrInfo, TargetSelectionDAGInfo and TargetLowering. Please review! More generally, I sugges...

...to do, and meanwhile I'm going to try to prepare a patch >> that does this. > > I've gone ahead and done this. With the attached patch applied, nothing in lib/Target/* or include/llvm/Target/* include anything from include/llvm/CodeGen. > > The .cpp files that moved are TargetELFWriterInfo, TargetFrameLowering, TargetLoweringObjectFile, TargetMachine, TargetOptions, TargetRegisterInfo and TargetSubtargetInfo. The .h files that moved are the matching headers for the .cpp files plus TargetInstrInfo, TargetSelectionDAGInfo and TargetLowering. > > Please review! More generally, I...

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

...ile I'm going to try to prepare a patch >>> that does this. >> >> I've gone ahead and done this. With the attached patch applied, nothing in lib/Target/* or include/llvm/Target/* include anything from include/llvm/CodeGen. >> >> The .cpp files that moved are TargetELFWriterInfo, TargetFrameLowering, TargetLoweringObjectFile, TargetMachine, TargetOptions, TargetRegisterInfo and TargetSubtargetInfo. The .h files that moved are the matching headers for the .cpp files plus TargetInstrInfo, TargetSelectionDAGInfo and TargetLowering. >> >> Please review! More genera...

.../Target/TargetAsmParser.h -- Installing: /usr/local/llvm-2.8/include/llvm/Target/TargetCallingConv.h -- Installing: /usr/local/llvm-2.8/include/llvm/Target/TargetCallingConv.td -- Installing: /usr/local/llvm-2.8/include/llvm/Target/TargetData.h -- Installing: /usr/local/llvm-2.8/include/llvm/Target/TargetELFWriterInfo.h -- Installing: /usr/local/llvm-2.8/include/llvm/Target/TargetFrameInfo.h -- Installing: /usr/local/llvm-2.8/include/llvm/Target/TargetInstrDesc.h -- Installing: /usr/local/llvm-2.8/include/llvm/Target/TargetInstrInfo.h -- Installing: /usr/local/llvm-2.8/include/llvm/Target/TargetInstrItineraries....

On Thu, Sep 30, 2010 at 3:08 PM, Samuel Williams <space.ship.traveller at gmail.com> wrote: > Hi, > > I might just be doing something stupid, but when I do > > $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. > $ sudo make install > > I don't get the expected headers in >        /usr/local/llvm-2.8/include/llvm > > It is

Hi, I might just be doing something stupid, but when I do $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. $ sudo make install I don't get the expected headers in /usr/local/llvm-2.8/include/llvm It is simply an empty directory. What am I doing wrong? This is on Mac OS X, CMake 2.8+ Kind regards, Samuel