similar to: [LLVMdev] Prevention register promotion at the isel codegen phase

Yes, this is very helpful! Thank you! How does this work when exiting a variable's liveness range? Will it automatically know to free the stack slot for reuse? -Joe On Sat, Nov 24, 2012 at 12:23 PM, Steve Montgomery < stephen.montgomery3 at btinternet.com> wrote: > Sorry, forgot to Reply-All. > > Begin forwarded message: > > *From: *Steve Montgomery

Sorry, forgot to Reply-All. Begin forwarded message: > From: Steve Montgomery <stephen.montgomery3 at btinternet.com> > Subject: Re: [LLVMdev] Prevention register promotion at the isel codegen phase > Date: 24 November 2012 17:09:58 GMT > To: Joseph Pusdesris <joe at pusdesris.com> > > I had a similar problem trying to implement reg-mem operations. The solution I

I was mucking around in FastISel, and was surprised to see the test llvm/test/CodeGen/Mips/emergency-spill-slot-near-fp.ll failed. This was surprising because it specifies -fast-isel=false. Does the Mips code generator use fast-isel even when you ask it not to? Thanks, --paulr

> > I was mucking around in FastISel, and was surprised to see the test > > llvm/test/CodeGen/Mips/emergency-spill-slot-near-fp.ll > > failed. This was surprising because it specifies -fast-isel=false. > > > > Does the Mips code generator use fast-isel even when you ask it not to? > > Thanks, > > --paulr > > This seems to be an all-targets bug.

> > > > I was mucking around in FastISel, and was surprised to see the test > > > > llvm/test/CodeGen/Mips/emergency-spill-slot-near-fp.ll > > > > failed. This was surprising because it specifies -fast-isel=false. > > > > > > > > Does the Mips code generator use fast-isel even when you ask it not > to? > > > > Thanks,

On Thu, 21 Dec 2006, Roman Levenstein wrote: > following: > 1) some of the fixed registers intervals are merged with some virtual > registers intervals > 2) later there is a need to spill one of the allocated registers, but > since all joined intervals are FIXED intervals now due to (1), they > cannot be spilled. Therefore, the register allocator loops for ever. > > I would

Hi, I need to force all variables of a basic block to spill, i.e., I can't allow basic blocks to share registers. I would like to know where is the most appropriate approach to implement that policy in LLVM. Looking at the LLVM source, it seems that the register allocator is the best choice because it controls the spilling, but I need to guarantee that this policy is not violated by post RA

Hi, all I want to make a function such as void add512(uint512_t *pz, const uint512_t *px, const uint512_t *py) { *pz = *px + *py; } # uint512_t means 512-bit unsigned integer register. Then, I make a sample code: >cat t.ll define void @add512(i512*noalias %pz, i512*noalias %px, i512*noalias %py) { %x = load i512* %px %y = load i512* %py %z = add i512 %x, %y store i512 %z, i512* %pz

Hi Andy and list, Just to give you a follow up, I was implementing a transformation pass just as you recommended at the time I sent the email to the list, but at that time I was worried that the code generator would change the order of the instructions created in the LLVM-IR. Indeed, that was the case. Some instructions after ISel were added between the volatile store instructions (which is

Hi, I was working on extending soft-float support for handling expansion of i64 and f64 into i16, i.e. on supporting the expansion of long values of illegal types into more then two parts. For that I modified SelectionDAGLowering::getValue() and several other functions. This seems to work now on my test-cases, but while testing it I ran into a different problem. I have the impression that I

That breaks the whole IR idea of using alloca to allocate/denote space for local variables, and then optimize those into SSA values when optimization proves that is OK. Also, for a lot of things, that attribute is simply impossible to implement. Any value that is live across a call needs to be spilled to memory. You cannot put an unspillable value in a callee preserved register, because you

Hi I am sorry. In my previous mail I mistyped the test case and disassembly. Test case -- -------------------------------------- char a; char fun () { return a; } -------------------------------------- Disassembly -------------------------------------- ; ModuleID = 'first.bc' @a = global i8 0 ; <i8*> [#uses=1] define i8 @fun(...) { entry: %tmp = load i8* @a ; <i8>

On May 12, 2008, at 8:21 AM, Sachin.Punyani at microchip.com wrote: > > When LLVM constructs the DAG for above case - it tries to promote > (during DAG construction phase - before any combine or legalize phase) > the return node operand to i32. > > I have few doubts here: > 1) If C language requires integer promotion of return value argument > then should it not be done by

Hi All, Please consider the following case Test case -- -------------------------------------- char a; void fun () { return a; } -------------------------------------- Following disassembly (using llvm-dis) is generated for the above test case -------------------------------------- ; ModuleID = 'first.bc' @a = internal global i8 0 ; <i8*> [#uses=1] define i8 @fun(...) { entry:

On Jul 26, 2012, at 9:43 AM, dag at cray.com wrote: > Jakob Stoklund Olesen <jolesen at apple.com> writes: > >> As far as I can tell, all sub-register operations involving sub_ss and >> sub_sd can simply be replaced with COPY_TO_REGCLASS: >> >> def : Pat<(v4i32 (X86Movsd VR128:$src1, VR128:$src2)), >> (VMOVSDrr VR128:$src1,

Hi All, I found some cases where a spill of a live range in a block is reloaded only in one of its successors, and there is no reload in other paths through other successors. Since the spill is reloaded only in a certain path, it must be okay to sink such spill close to its reloads. In the AArch64 code below, there is a spill(x2) in the entry, but this value is reloaded only in %bb.1, not in

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Jun Lim via llvm-dev Sent: Thursday, February 22, 2018 11:05 AM Hi All, I found some cases where a spill of a live range in a block is reloaded only in one of its successors, and there is no reload in other paths through other successors. Since the spill is reloaded only in a certain path, it must be okay to sink such

On Wed, 15 Apr 2020 at 03:36, John Brawn <John.Brawn at arm.com> wrote: > > > Could you please point out what am I doing wrong in the patch ? > > It's because you're getting the function name by doing > callee->getName().str().c_str() > The str() call generates a temporary copy of the name which ceases to exist outside of this expression > causing the

OK, I get it. The essence of this problem is that a node can be covered exactly and just once but its result can be referred multiple times for a tree pattern matching isel. So to duplicate a load node (only if we can!) is convenient to conquer that case. The truth is, in pattern (add (load) (load)), source operands are memory addresses, and thus it can be treated as (addmm address,

I'll give that a shot, thanks! -Joe On Sun, Dec 2, 2012 at 12:06 PM, Triple Yang <triple.yang at gmail.com> wrote: > OK, I get it. > > The essence of this problem is that a node can be covered exactly and > just once but its result can be referred multiple times for a tree > pattern matching isel. So to duplicate a load node (only if we can!) > is convenient to