similar to: [LLVMdev] PR19267 - Add a feature to clobber non-calle-save regs in the prolog.

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

Hi All, When seeing the title "Prolog/Epilog Code Insertion", I'd expect something about XXXFrameLowering.cpp (particular about emitPrologue/emitEpilogue). But the document [1] is about unwind. Is it placed at the right place/section? Thanks. [1] http://llvm.org/docs/CodeGenerator.html#prolog-epilog-code-insertion Regards, chenwj -- Wei-Ren Chen (陳韋任) Homepage:

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

Thanks for reviving this topic! Interestingly we have essentially the same fix you mention below ( https://reviews.llvm.org/D62639) as a local change in our Wind River version of LLVM. The reason we didn't try to push it upstream (and in fact have considered removing it) is due to an unfortunate side-effect which is either "expected" or a "bug" depending on your

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.

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

On Jun 4, 2010, at 3:05 AM, Sylvere Teissier wrote: > > In my target the CALL instruction change the link Register %LR > In the target InstrInfo.td I have "Defs=[LR]" on the CALL instruction > definition to handle that. So your CALL instructions are clobbering your callee-saved registers, eh? ;-) > It works well with others registers allocators: when there is a call

Documentation and other bugs with postscript(): 1. This code crashes R (it asks for a font that isn't there): postscript() plot(0:1,0:1) text(0.5,0.5,'crash',font=6) The bug appears to be in the FixupFont routine in plot.c; on line 236, it checks that the font number is in the range 1..32. Later this crashes PostScriptStringWidth in devPS.c, because only fonts numbered 1..5

Specifying -no-implicit-float prevents LLVM from using non-GPR registers for purely integer operations. This is useful for operating systems (such as Wind River's VxWorks) that support tasks that do not save all registers on context switch. This presents an interesting problem for variadic functions that may optionally take non-integer arguments (e.g. printf style functions). Should non-GPR

In your sequences in asm/paravirt.h, you explicitly save the caller-save regs: static inline void raw_local_irq_restore(unsigned long f) { __asm__ __volatile__(paravirt_alt("pushl %%ecx; pushl %%edx\n\t" "pushl %1; call *%0\n\t" "popl %1; popl %%edx; popl %%ecx", PARAVIRT_RESTORE_FLAGS) : : "m" (paravirt_ops.restore_fl),

Hi Jean-Marc, Thanks a lot for reviewing this huge assembly function! silk_warped_autocorrelation_FIX_c()'s kernel part is for( n = 0; n < length; n++ ) { tmp1_QS = silk_LSHIFT32( (opus_int32)input[ n ], QS ); /* Loop over allpass sections */ for( i = 0; i < order; i++ ) { /* Output of allpass section */ tmp2_QS = silk_SMLAWB(

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

This is a great idea. But the order (psEncC->shapingLPCOrder) can be configured to 12, 14, 16, 20 and 24 according to complexity parameter. It's hard to get a universal function to handle all these orders efficiently. Any suggestions? Thanks, Linfeng On Mon, Feb 6, 2017 at 12:40 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Linfeng, > > On 06/02/17 02:51 PM,

On Wed, 9 Jun 2004, Vladimir Prus wrote: > > The X86 backend has this code: > > X86TargetMachine::X86TargetMachine(const Module &M, IntrinsicLowering *IL) > : .... > FrameInfo(TargetFrameInfo::StackGrowsDown, 8/*16 for SSE*/, 4), > > That is, it uses "4" as local area offset. Based on prior discussion this > should mean that the local

Hello, I would like to reserve a register or make it available to the register allocator depending if the stack is used inside a function or not. By using the stack i mean the following: if all regs are spilled so that frame space has to be allocated, arguments passed through the stack and allocas. I know how to get the last two options when the register allocator is run since that info is

On Tuesday 15 December 2009 18:01, Jim Grosbach wrote: > For a usage example, I've included in the patch the modification to > use the constraint for the STREX ARM instruction. Your example is: constraints = "@early $success" Why not spell it as: constraints = "$success != $src", "$success != $ptr" The grammar would change to something like:

Hi Jean-Marc, Thanks for your suggestions. Will get back to you once we have some updates. Linfeng On Mon, Feb 6, 2017 at 5:47 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Linfeng, > > On 06/02/17 07:18 PM, Linfeng Zhang wrote: > > This is a great idea. But the order (psEncC->shapingLPCOrder) can be > > configured to 12, 14, 16, 20 and 24 according to

All, I've attached a small patch that adds a new early-clobber operand constraint option to TableGen and would like to get feedback before proceding. As background, the ARM store-exclusive instruction (STREX) stores a success result code in a register operand, and that register cannot be the same register as either the source of the value to be stored, or the base address.

Hi all, I am currently working on AMDGPU inline assembly and encountered problem with naming clobber registers in asm constraints. It looks like by default LLVM tries to match register specified in constraint to register name of register definition in .td file but not to the AsmName for this register. For example if we have register definition: def MYReg0 : Register<"r0", 0>;