similar to: Question about Prolog/Epilog Code Insertion

Hello, I'd like to upstream our work over the time which the community would benefit from. This is a part of effort toward minimizing code size presented in here <https://llvm.org/devmtg/2020-02-23/slides/Kyungwoo-GlobalMachineOutlinerForThinLTO.pdf>. In particular, this RFC is about optimizing prolog and epilog for size. *Homogeneous Prolog and Epilog for Size Optimization, D76570

Hi Vedant, Thanks for your interest and comment. Size-optimization improves page-faults and a start-up time for a large application, which this enabling also followed. Even though I didn't see a large regression/complaint on a CPU-bound case, which is not a typical case for mobile workload, I wanted to be precautious of enabling it by default. However, as with default outlining case, I

I am new to the LLVM, and need some help with this points. 1. how can we add special code for the Prolog/Epilog for some certain functions, this should be done with machinefunction pass, rt? 2. Basically, I want to get the function stack frame, that is the size and the initial position. I found int64_t llvm::MachineFrameInfo::getObjectSize ( int *ObjectIdx* ) const[inline] This method is

I've been looking through the code for pologue/epilogoue generation and noticed this oddity: void PEI::replaceFrameIndices(MachineFunction &Fn) { [...] for (MachineBasicBlock::iterator I = BB->begin(); I != BB->end(); ) { [...] if (I->getOpcode() == FrameSetupOpcode || I->getOpcode() == FrameDestroyOpcode) { [...] } else {

I'm trying to implement something similar to this: http://gcc.gnu.org/wiki/SplitStacks in LLVM. The reason I want this is so that I can have dynamically growing and shrinking stacks in my programming language. In order to do this, I need to be able to check for overflow of a stack frame. The methods of doing this are outlined in the link above, but my intention is to pass the current stack

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:

Dear all, I am looking to output assembly comments in my emitPrologue() function, just for my own readability. Searching for a way to do this found me this thread - http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043722.html, which says that the best way to output comments from somewhere like emitPrologue() is to: 1. Create an MDString for the comment. 2. Attach it to an LLVM

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

On Wed, Apr 7, 2010 at 12:43 PM, Arlen Cox <arlencox at gmail.com> wrote: > I'm trying to implement something similar to this: > http://gcc.gnu.org/wiki/SplitStacks in LLVM.  The reason I want this > is so that I can have dynamically growing and shrinking stacks in my > programming language.  In order to do this, I need to be able to check > for overflow of a stack frame.

Hi! > diff --git a/lib/CodeGen/StackSegmenter.cpp b/lib/CodeGen/StackSegmenter.cpp > new file mode 100644 > index 0000000..5ffb8f2 > --- /dev/null > +++ b/lib/CodeGen/StackSegmenter.cpp > @@ -0,0 +1,48 @@ > +//===-- StackSegmenter.h - Prolog/Epilog code insertion -------*- C++ -* --===// > > The comment is obviously incorrect. Thanks. So much for lifting file

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

How/where are function prologs and epilogs generated, is it bespoke C++ code or TableGen generated ? If someone could point me in the right direction please. Many thanks in advance, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090409/fb3336e4/attachment.html>

I started to implement inlining of the stack probe function based on Microsoft's inlined stack probes in https://github.com/Microsoft/llvm/tree/MS. Do we know why the stack pointer cannot be updated in a loop (which results in ideal code)? I noticed that was commented in Microsoft's code. I suspect this is due to debug or unwinding information, since it is allowed on Windows x86-32. I

Hi list, I am trying to implement the technique outlined in the following paper: http://www.cs.umd.edu/~mwh/papers/martin10ownership.html in LLVM. My approach so far involves the use of an IR level transform (via runOnFunction) to identify memory loads and stores. One thing I need to do (I am pretty sure I need to do it at least) is automatically mark each stack frame as "owned" by the

Hi Sanjoy, The patch generally looks fine except for this part: diff --git a/lib/CodeGen/StackSegmenter.cpp b/lib/CodeGen/StackSegmenter.cpp new file mode 100644 index 0000000..5ffb8f2 --- /dev/null +++ b/lib/CodeGen/StackSegmenter.cpp @@ -0,0 +1,48 @@ +//===-- StackSegmenter.h - Prolog/Epilog code insertion -------*- C++ -* --===// The comment is obviously incorrect. diff --git

Current set of patches for my work on segmented stacks. Go / dragonegg seems to work when using this code (I still haven't run any rigorous tests yet). Thanks! (Also on https://github.com/sanjoy/LLVM/tree/segmented-stacks) -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name:

> -----Original Message----- > From: mbraun at apple.com [mailto:mbraun at apple.com] > Sent: Friday, February 17, 2017 3:15 PM > To: Alex Bradbury > Cc: llvm-dev; Adrian Prantl; Eric Christopher; Robinson, Paul > Subject: Re: [llvm-dev] RFC: Setting MachineInstr flags through > storeRegToStackSlot > > Can someone familiar with debug info comment on whether it matters

Hi, This is a proposal about epilog loop vectorization. Currently Loop Vectorizer inserts an epilogue loop for handling loops that don't have known iteration counts. The Loop Vectorizer supports loops with an unknown trip count, unknown trip count may not be a multiple of the vector width, and the vectorizer has to execute the last few iterations as scalar code. It keeps a scalar copy of

Hi James, I also think that refactoring the code generation part is a great idea. That code is very complicated and difficult to maintain. I’ve wanted to rewrite that code for a long time, but just have never got to it. There are quite a few edge cases to handle (at least in the current code). I’ll take a deeper look at your patch. The abstractions that you mention, Stage and Block, are good

I investigated the MachineFunctionPass (that is runOnMachineFunction, I believe). In my experimentation it didn't seem that the MachineFrameInfo was populated (it consistently said that the stack depth was 0, for example). I might have been doing something wrong? On Fri, Jul 8, 2011 at 5:21 PM, John Criswell <criswell at illinois.edu> wrote: > On 7/8/11 4:09 PM, Andrew Ruef wrote: