similar to: [LLVMdev] moving from lib/Target and lib/CodeGen

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

I have mixed feeling about this. While this does separate 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

On 12 December 2011 12:22, Evan Cheng <evan.cheng at apple.com> wrote: > I have mixed feeling about this. While this does separate 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

Hi All, I'm dealing with a problem where the spill/restore instructions inserted during scavenging span an adjustment of the SP/FP register. The result is that despite the base register (SP/FP) being changed between the spill and the restore, both store and load use the same immediate offset. I see code in the PEI (replaceFrameIndices) that is supposed to track the SP/FP adjustment:

Hi all, This is my proposal for how to solve the problem we have with function attributes that affect code generation changing between functions. (This is mostly a problem for LTO.) Please take a look at this proposal, and let me know if you have any questions or comments. Cheers! -bw CodeGen Context =============== The back-end's

On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote: > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if the > attributes changed). Do you have another solution in mind ? I don't really understand this. TargetMachine and TTI may be quite expensive to initialize. Doing so for

CallFrameSetupOpcode is a pseudo opcode like X86::ADJCALLSTACKDOWN64. That means when the code is expected to be called before the pseudo instructions are eliminated. I don't know why it's not the case for you. A quick look at PEI code indicates the pseudo's should not have been removed at the time when replaceFrameIndices are run. Evan On Sep 25, 2013, at 8:57 AM, Krzysztof

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 >

Consider this example: --- ex.ll --- declare void @bar() ; Function Attrs: nounwind optsize define void @main() { entry: %hin = alloca [256 x i32], align 4 %xin = alloca [256 x i32], align 4 call void @bar() ret void } ------------- Freshly built llc: llc -O2 -march=x86 < ex.ll -print-before-all # *** IR Dump Before Prologue/Epilogue Insertion & Frame Finalization ***: #

I'm trying to build LLVM on OPENBSD current with today's svn (feb 23), and it fails to build with the following errors: llvm[2]: Compiling ELFWriter.cpp for Release build In file included from ELFWriter.cpp:51: /root/llvm/include/llvm/Target/TargetLoweringObjectFile.h:345: error: virtual outside class declaration /root/llvm/include/llvm/Target/TargetLoweringObjectFile.h:345: error:

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/~chenwj

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

I've prepared a preliminary patch with the intention of implementing PPC-EABI subtarget features for applications that run in a standalone embedded environment. https://reviews.llvm.org/D26344 The most significant difference compared with the SVR4 ABI is the use of SDA (small data area). This allows full-word constants and data to be grouped into small-data sections accessed using relocated

Just pinging this patch for review, particularly from PPC maintainers: https://reviews.llvm.org/D26344 It's now rebased for the latest master commits, `check-all` test results match those of the upstream base. There is also a clang driver patch, extending PPC target support for the `-G` flag: https://reviews.llvm.org/D26345 And lld patch implementing the _SDA_BASE_ symbols and includes an

----- Original Message ----- > From: "Jack Andersen via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, November 16, 2016 10:39:53 PM > Subject: Re: [llvm-dev] [MC] Target-Independent Small Data Section Handling > > Just pinging this patch for review, particularly from PPC > maintainers:

The code has changed a lot over the years. Looks like at some point of time the assumption was broken. calculateCallsInformation() may have eliminated the pseudo set up instructions already. // If call frames are not being included as part of the stack frame, and

Thanks, I'll look into that. Still, the case where the function does not call anything remains---in such a situation there are no ADJCALLSTACK pseudos, so regardless of what that function you pointed at does, there won't be any target-independent information about the SP adjustment by the time the frame index elimination runs. Would it make sense to have ADJCALLSTACK pseudos every

I am not seeing this happening, at least not for unreachables that follow calls to 'noreturn' functions. On Apr 14, 2014, at 3:48 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hello > > x86 backend emits ud2 instruction in this case > > On Mon, Apr 14, 2014 at 1:46 PM, Vadim Chugunov <vadimcn at gmail.com> wrote: >> Hi, >> Is it

> I just tried the above code in a .s file and it worked fine for me. > Can you show exactly what you’re seeing that looks wrong? Thanks Jim. I can only reproduce the issue when that code is inline assembly in a bitcode file. Attached is a bitcode file and Makefile to demonstrate. Calling 'make' will dump two object files 'c.o' and 'asm.o'. The former is created

hi, I am trying to build the llvm trunk with make. I am trying a debug build and I am ending with the following build error. /home/rajika/projects/llvm/llvm/lib/Target/TargetLoweringObjectFile.cpp: In member function ‘virtual bool llvm::TargetLoweringObjectFileMachO::shouldEmitUsedDirectiveFor(const llvm::GlobalValue*, llvm::Mangler*) const’: