search for: frameindexes

Thanks Anton and Krzysztof! Here is the dump using the -debug flag. At this point I am not making much sense of this, would it be too much to ask if one of you could walk me through one of these lines? One thing that I didn't point out is that I never defined any separate floating point registers, not sure if this will pose any issue? Thanks again for your time! Jeff jeff at

Suppose I have a target that does not have register+constant addressing mode. Then, I have DAG like: (store ..., (frameindex)) Targets like SPARC have the following patterns to catch this: def ADDRri : ComplexPattern<i32, 2, "SelectADDRri", [frameindex], []>; def STri : F3_2<3, 0b000100, (outs), (ins MEMri:$addr, IntRegs:$src),

Hi, I am having issues running a new backend that I created for a new architecture. I suspect these errors may have something to do with how I have the string setup in LLVMTargetMachine() below? Also - It would be great if someone could point me to a document that describes some of these error messages? For example what does t26 ..t4 mean? Thanks in advance for taking your valuable time to help

On Dec 3, 2007, at 12:53 PM, Vladimir Prus wrote: > > Suppose I have a target that does not have register+constant > addressing mode. Then, I have DAG like: > > (store ..., (frameindex)) > > Targets like SPARC have the following patterns to catch this: > > def ADDRri : ComplexPattern<i32, 2, > "SelectADDRri", [frameindex], []>; > def STri :

Evan Cheng wrote: > > On Dec 3, 2007, at 12:53 PM, Vladimir Prus wrote: > >> >> Suppose I have a target that does not have register+constant >> addressing mode. Then, I have DAG like: >> >> (store ..., (frameindex)) >> >> Targets like SPARC have the following patterns to catch this: >> >> def ADDRri : ComplexPattern<i32, 2,

Hi All I'm having nightmares with FrameIndexes during my backend development :( I have ComplexPatterns defined for my two addressing modes (RR and RI). Most of the time, FrameIndex operands appear to be on load/store nodes, in which case everything works fine as my custom addressing modes matchers work fine. Unfortunately, I now have an add n...

On Tue, Jun 25, 2019 at 9:59 AM Tim Northover <t.p.northover at gmail.com> wrote: > On Tue, 25 Jun 2019 at 06:26, Gleb Popov via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > >> While the store is being selected LLVM will just treat the value being > >> stored as a generic pointer-width integer unless you have written a > >> specific pattern for

On Wed, Jun 26, 2019 at 12:38 PM Tim Northover <t.p.northover at gmail.com> wrote: > Hi Gleb, > > On Wed, 26 Jun 2019 at 07:28, Gleb Popov <6yearold at gmail.com> wrote: > > def StoreStackF : InstRI<2, (outs), (ins IntRegs:$reg, i32imm:$i), > > "storestackf $reg, [$i]", [(store_stack i32:$reg, > AddrFI:$i)]>; > > >

Hi all, I've been working on a backend of our architecture and noticed llvm performs following combining although one of operands is FrameIndex. Combining: t114: i64 = add FrameIndex:i64<0>, Constant:i64<56> Creating new node: t121: i64 = or FrameIndex:i64<0>, Constant:i64<56> ... into: t121: i64 = or FrameIndex:i64<0>, Constant:i64<56> This

On Mon, Jun 24, 2019 at 4:08 PM Tim Northover <t.p.northover at gmail.com> wrote: > On Mon, 24 Jun 2019 at 12:16, Gleb Popov via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > 1. Where does it come from? Can I do anything to make it not appear? > > It comes from something like: > > %ptr = alloca i8 > %var = alloca i8* > store i8* %ptr, i8**

Hi, I'm try to lower the store LLVM-IR instruction as per the following LLVM IR program: *** IR Dump After Module Verifier *** define void @storeloadi32() { %ptr = alloca i32 store volatile i32 12, i32* %ptr ret void } The target instruction is associated to the store like this: def MOVSUTO_A_iSLr : CLPFPU_A_iSLr<0b1000001101,

Hello. After "Initial selection DAG" stage I get a DAG with node t14: ch = store<(store 4 into %ir.p45, align 8, addrspace 1)> t10, FrameIndex:i32<2>, FrameIndex:i32<3>, undef:i32 1. Where does it come from? Can I do anything to make it not appear? 2. If not, how do I change it so that the operand being stored would be first loaded into a register, and that register

>> I'm trying something cunning/crazy with the stack - implementing it in a type of memory that can only be addressed via immediates. >> >> I've got this mostly working. However, I came across a problem which I've been unable to work around: lowering the IR (even without any optimisations enabled) often requires the pattern: >> >> i32 = FrameIndex

Hi Mark, >> Sounds like your load / store address selection routine isn't working >> like what you expected. >> > > Thanks for the reply. Unfortunately, this doesn't seem to be the problem. do you handle truncating stores and extending loads? Ciao, Duncan.

Hey all, I am trying to implement a subtarget for the X86 architecture that only has 64 bit Registers. While running LLC on the IR for a very simple program, llc fails on an assertion that says it doesn't know how to promote ISD::FRAMEINDEX. I've tried to look for why how to promote the frameindex which is stored in a i32 variable to an i64 variable but can't seem to find where

Drear there: The problem I have is to lower an intrinsic function like this ” float @llvm.write.arg(flaot %src, float* %dst) “ I am lowering it with INTRINSIC_W_CHAIN, so the return value and the value to write to dst are generated with some operations using src: " // it is the frame index node corresponding to input pointer SDvalue frindex = Op.getoperand(3); … SDValue returnValue =

Hi, all, I have been recently porting a backend for our experimental DSP. It has a regular register file for ALU, naming it R registers, and another register file (J registers) for memory access. Both R registers and J registers are 32-bit. Since LLVM cannot distinguish 32-bit integers or pointers during register allocation, I have to define J as 64-bit, although it's physically 32-bit. This

http://llvm.org/bugs/show_bug.cgi?id=14792 Problem: In the i386 ABI Page 3-10, it said that the stack is aligned. However, the two example code show that does not handle the alignment correctly when using variadic function. For example, if the size of the first argument is 17, the overflow_arg_area in va_list will be set to "address of first argument + 16" instead of "address of

Hi there, I have a mem address pattern basically copied from Sparc: def ADDRri : ComplexPattern<iPTR, 2, "SelectADDRri", [frameindex],[]> It can match FrameIndex<0> but was unable to match FrameIndex<1>. What is the difference between the two? How to match FrameIndex<1>? Thanks, Xiaochu -------------- next part -------------- An HTML attachment was scrubbed...

Hi, I'm trying to optimize the 'extract_vector_elt' for my SIMD microcontroller. The idea is, during DAG combination, to merge load/extract sequence into an architecture specific node. During Instruction Selection, this specific node will be target selected to an architecture specific instruction. By 'combination of DAG nodes' I understand 'replacing a set of DAG nodes by