similar to: [LLVMdev] Legalizing FrameIndex

Hi, I'm stumped by how to handle fpowi. Here is the context: my architecture has i64, f32, and f64 registers. No i32. For calls & returns, we promote i32 to i64. There is no support in the architecture to perform fpowi - it has to go through the runtime. I'm using gfortran + dragonegg + llvm3.4 to generate .ll files via plugin. The fortran expression REAL = REAL ** INTEGER*4

Hey Everyone, I understood this a little differently (well, I do have direct contact with Sumeeth given that we both work in the same lab). Allow me to try and explain his proposal. We are trying to optimise out instructions from a program (JIT-compiled OS Kernels or JIT-compiled Web Server code) during run time and we have this hypothesis that some of the decisions are best taken by the

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Kaylor, Andrew > Subject: Re: [LLVMdev] [Proposal] Adding callback mechanism to Execution Engines > If the function is in a statically linked module, you need to do something to explicitly expose it. With > the older JIT engine you can use addGlobalMapping as Yaron suggests, but I

Hey guys, I'm trying to implement a simplified X86_64 architecture targeting backend for LLVM. While I have figured that I can introduce the intended architecture as a subtarget of X86 in X86.td, what i don't understand is how the registers specified in X86RegisterInfo.td and the ISA in X86InstrInfo.td are correlated with each sub-architecture. Where are the correlations defined? The

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 node which has a FrameIndex operand (this results

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 :

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

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...

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,

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),

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)]>; > > >

Here's the IR I'm trying to compile for my backend, a 16-bit CPU: ; ModuleID = 'foo.c' source_filename = "foo.c" target datalayout = "E-m:e-p16:16:16-i1:16:16-i8:16:16-i16:16:16-i32:16:16-i64:16:16-S16-n16" target triple = "tms9900" @global_var = common global i16 0, align 2 ; Function Attrs: noinline nounwind optnone define signext i16 @dothis(i16

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,

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

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

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

Hey all, I am trying to implement a new subtarget for the X86 target that has only 64 bit registers and instructions and a very minimal ISA excluding any FPU instructions etc. I have made the required changes to the instructions such that all the instructions that I don't wish to use have a required<> clause that precludes them from being utilised when compiling for this subtarget.

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 recently started helping with the LLVM AVR backend [1]. The AVR is an 8 bit core with pointer type i16. That makes pointers illegal in the SelectionDAG. As far as I understand it, it is the backends job to legalize these nodes by using the ReplaceNodeResults/LowerOperation callbacks. Is that about right? I have the feeling that the symbolic nodes carrying pointers, like FrameIndex are

On 27 Jun 2015, at 16:13, escha <escha at apple.com> wrote: > >> >> Hi, >> >> I recently started helping with the LLVM AVR backend [1]. The AVR is an 8 bit core with pointer type i16. That makes pointers illegal in the SelectionDAG. As far as I understand it, it is the backends job to legalize these nodes by using the ReplaceNodeResults/LowerOperation callbacks.