similar to: [LLVMdev] eliminateCallFramePseudoInstr belongs in TargetRegisterInfo or TargetFrameLowering

> ISTM that eliminateCallFramePseudoInstr belongs in > TargerFrameLowering, since it's being used during prolog/epilog > insertion. Moving it there would avoid the code duplication and > possibly other layering problems. > What do you think Go ahead and move. It's s historical artifact why it is inside TRI. -- With best regards, Anton Korobeynikov Faculty of Mathematics

Heads up for out-of-tree targets: in r265036, TargetFrameLowering::eliminateCallFramePseudoInstr changed to return an iterator to the next instruction, instead of returning void. If your target was previously doing "MBB.erase(I); return;" your code should now be doing "return MBB.erase(I);". Thanks, Hans

For a Z80 backend, "eliminateCallFramePseudoInstr()" shall adjust the stack pointer in three possible ways, e.g. after a function call, depending on the amount (= adjustment size) *and some other rules*: 1. via one or more target "pop <reg>" instructions (SP increments +2 per instruction), using an unused reg (disregarding the contents after the operation), followed

Hi, During isel lowering, the backend insertes CALLSEQ_START / CALLSEQ_END target independent nodes to the DAG. These are then selected to X86 specific instructions ADJCALLSTACKDOWN / ADJCALLSTACKUP. At these point, they have a constant arguments which corresponds to the fixed frame size for argument passing. But the size of the stack frame isn't finalized until frame layout has

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

Hi Evan, I incoporated the changes you request but to the following i have got a question: > Also, moving the option > there will allow us to change fastcc ABI (callee popping arguments) > only when this option is on. See Chris' email: I am not to sure on that. because that would make modules compiled with the flag on incompatible with ones compiled without the flag off as

Hello, I am trying to add an instruction before each function call to add/ subtract the stack pointer by a value specified at the command line. I wonder if I can do that during lowering. For example, in X86TargetLowering::LowerCALL. I appreciate it if you give me some hints how and where I can do that. Thank you, Babak

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 ***: #

On Oct 5, 2007, at 2:42 AM, Arnold Schwaighofer wrote: > Hi Evan, > I incoporated the changes you request but to the following i have got > a question: > >> Also, moving the option >> there will allow us to change fastcc ABI (callee popping arguments) >> only when this option is on. See Chris' email: > > I am not to sure on that. because that would make

Comments: CheckDAGForTailCallsAndFixThem - 1. for (SelectionDAG::allnodes_iterator BE = DAG.allnodes_begin(), + BI = prior(DAG.allnodes_end()); BI != BE; BI--) { Please use pre-decrement instead of post-decrement. 2. The function is slower than it should be. You are scanning all the nodes in the DAG twice. You should just examine DAG.getRoot() to make determine whether it's a

On Oct 5, 2007, at 10:41 AM, Evan Cheng wrote: > > On Oct 5, 2007, at 2:42 AM, Arnold Schwaighofer wrote: > >> Hi Evan, >> I incoporated the changes you request but to the following i have got >> a question: >> >>> Also, moving the option >>> there will allow us to change fastcc ABI (callee popping arguments) >>> only when this option is

Hi, I'm interested in finding ways to reduce code size. LLVM's MergeFunctions pass seems like a promising option, and I'm curious about its status in tree. Enabling MergeFunctions gives a 1% code size reduction across the entire iOS shared cache (a collection of a few hundred system-critical DSO's). The numbers are even more compelling for Swift code. In fact, the swift compiler

On 18 December 2014 at 21:32, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > I think this will help one facet of your problem: > http://reviews.llvm.org/D6584 I don't think so, because the tests don't time out, it's a buffering issue... --renato

I don't see a way to create a ConstantDataVector from Constant or form APFloat though. Did I oversee that? Is the solution to had a new get function in ConstantDataVector to allow that? Any hint on what would be the right fix otherwise? Thomas -----Original Message----- From: Jonathan Roelofs [mailto:jonathan at codesourcery.com] Sent: Wednesday, January 14, 2015 10:30 AM To: Raoux, Thomas

On Mon, Nov 2, 2015 at 7:19 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Why does this need to be an intrinsic (as opposed to generic "unknown > function" to llvm)? > > Secondly, have you looked into a volatile store / load to an alloca? That > should work with PNaCl and WebAssembly. > > E.g. > > define i32 @blackbox(i32 %arg) { >

Hello, I'm playing around with some LEA-related code generation on x86-64 (trunk LLVM & Clang), and I run into a case I don't understand: $ cat takeaddr.c int* bar(int table[10]) { return &table[2]; } $ clang -cc1 -emit-llvm takeaddr.c $ cat takeaddr.ll ; ModuleID = 'takeaddr.c' target datalayout =

Ha here is what I was missing. Thanks Jon. It still seems to me that the transformation of LLVM IR is invalid is that right? I assume we shouldn't be converting APFloat to float in order to avoid such problems? -----Original Message----- From: Jonathan Roelofs [mailto:jonathan at codesourcery.com] Sent: Wednesday, January 14, 2015 9:39 AM To: Raoux, Thomas F; LLVM Developers Mailing List

On 06/01/17 21:51, Andy Lutomirski wrote: > On Fri, Jan 6, 2017 at 10:32 AM, Robin Murphy <robin.murphy at arm.com> wrote: >> On 06/01/17 17:48, Jean-Philippe Brucker wrote: >>> Hi Will, >>> >>> On 20/12/16 15:14, Will Deacon wrote: >>>> Booting Linux on an ARM fastmodel containing an SMMU emulation results >>>> in an unexpected I/O

On 06/01/17 21:51, Andy Lutomirski wrote: > On Fri, Jan 6, 2017 at 10:32 AM, Robin Murphy <robin.murphy at arm.com> wrote: >> On 06/01/17 17:48, Jean-Philippe Brucker wrote: >>> Hi Will, >>> >>> On 20/12/16 15:14, Will Deacon wrote: >>>> Booting Linux on an ARM fastmodel containing an SMMU emulation results >>>> in an unexpected I/O