search for: globaladdresses

Hello, Brief background: We are trying to support 64 bit pointers in RISCV 32 bit backend http://lists.llvm.org/pipermail/llvm-dev/2019-June/132805.html To pass the legalizer we plan to break the 64 bit GlobalAddress into 32 bit GlobalAddress having the other 32 bit glued to the node. We could not find a direct way to convert the 64 bit GlobalAddress Node into a 32 bit node. For a GlobalAddress

> > I don't think there's a real shortage of those, but I confess I'm not > sure why that's related. You'd need a representation for the LUI and > ADDI after instruction selection anyway. Yeah at the end we need a representation for LUI and ADDI. We were trying to break the 64 bit address from GlobalAddress node into two i32 register. We will add custom load/store

I've been looking at GlobalAddress lowering strategy recently and was wondering if anyone had any ideas, insights, or experience to share. ## Background When lowering global address, which is typically done in FooTargetLowering::LowerGlobalAddress you have the option of folding in the global offset into the global address or else emitting the base globaladdress and a separate ADD node for the

More information on this... still not working When I build the project for Debug and run the program, the following message is printed before assert. NODE: 0x937bac8: i64 = GlobalAddress <i32* @var> 0 I guess it is expecting that GlobalAddress be legalized before reaching ExpandOp(). I haven't implemented anything for ISD::GlobalAddress, and that may explain it, however, I

...gisters that can be used only to hold pointers (indirect addresses). All operations on the target are 8-bit operations, so it takes two 8-bit loads to load these pointer registers. We want LLVM to automatically expand all types to 8-bit values. The problem is that LLVM does not expand GlobalAddresses, which are 16-bit values. This in turn means that you have to specify a 16-bit register class, and once you specify a 16-bit register class, LLVM does not further expand 16-bit values. Any suggestions on how to model this into LLVM? TIA, Sanjiv -------------- next part -------------- An...

Have you read http://llvm.org/docs/WritingAnLLVMBackend.html and http://llvm.org/docs/CodeGenerator.html ? http://llvm.org/docs/WritingAnLLVMBackend.html#instruction-selector describes how to define a store instruction. -Eli On 7/6/2017 6:51 PM, hameeza ahmed via llvm-dev wrote: > Please correct me i m stuck at this point. > > On Jul 6, 2017 5:18 PM, "hameeza ahmed"

> > I don't think there is code in Legalizer to expand GlobalAddress. But you > can custom lower it. X86 custom lower GlobalAddress nodes for a different > reason. > > Evan > Hmmm...That means we have to make i16 as a legal type (since GlobalAddresses are 16-bits) and custom lower all 16-bit operations to 8-bit operations. I was thinking to take advantage of the already present ExpandOp infrastructure. -Sanjiv

Every GlobalAddress has a GlobalValue, Every GlobalValue is a PointerType, Every PointerType has an AddressSpace. So is it ok to add a method getAddressSpace in GlobalAddressSDNode class itself? Currently we have to do GSDN->getGlobal()->getType()->getAddressSpace(). - Sanjiv

Here is a last example to illustrate my concern. The problem is about the lowering of node t13. Initial selection DAG: BB#0 '_start:entry' SelectionDAG has 44 nodes: t11: i16 = Constant<0> t0: ch = EntryToken t3: ch = llvm.clp.set.rspa t0, TargetConstant:i16<392>, Constant:i32<64> t5: ch = llvm.clp.set.rspb t3,

On Tue, 11 Sep 2007 Alireza.Moshtaghi at microchip.com wrote: > More information on this... still not working > When I build the project for Debug and run the program, the following > message is printed before assert. > > NODE: 0x937bac8: i64 = GlobalAddress <i32* @var> 0 This implies that your target uses 64-bit pointers, but that it doesn't have a 64-bit register

On Thu, Jul 11, 2019 at 10:21 PM Tim Northover <t.p.northover at gmail.com> wrote: > On Thu, 11 Jul 2019 at 17:16, Reshabh Sharma <reshabhsh at gmail.com> wrote: > > We thought LUI and ADDI pair will be good to store the values in a i32 > register. > > With you so far, I think. To be explicit, to materialize a full 64-bit > pointer you'd need 4 instructions:

also i further run the following command; llc -debug filer-knl_o3.ll and its output is attached here. by looking at the output can we say that legalization runs fine and the error is due to instruction selection/ pattern matching which is not yet implemented? so do i need to worry and try to correct it at this stage or should i move forward to implement instruction selection/ pattern matching?

The DAG dumping will try to print some of the nodes "inline" (i.e. where they are used) to make the output more readable, so the dump of the DAG may not strictly reflect the node ordering. -Krzysztof On 5/4/2018 8:18 AM, Dominique Torette via llvm-dev wrote: > Here is a last example to illustrate my concern. > > The problem is about the lowering of node t13. > >

Hi, Is there a kind of scope mechanism in the instruction lowering pattern language in order to control where instructions are inserted or how they are later reordered during the SelectionDiag linearization? I know the glue chain that stick instructions together. But such mechanism in not provided in instruction lowering pattern. I'm facing many situations where some patterns are lowered into

Thank you Chris, I had the pointer size wrong. I fixed it and now it passes that point as expected :) which takes me to a second question: The processor that I am working on is 8-bit and has Harvard architecture; this implies different pointer types (sizes) to objects in data memory or program memory (functions or data in program memory) At this moment, I am just using only one pointer size

...d only to hold pointers (indirect addresses). > > All operations on the target are 8-bit operations, so it takes two 8- > bit loads to load these pointer registers. > > We want LLVM to automatically expand all types to 8-bit values. > > The problem is that LLVM does not expand GlobalAddresses, which are > 16-bit values. > This in turn means that you have to specify a 16-bit register class, > and once you specify a 16-bit register class, LLVM does not further > expand 16-bit values. I don't think there is code in Legalizer to expand GlobalAddress. But you can cus...

Sure I will split it and put it in two patches. Give me few hours. I need to test those patches. Sirish On 4/19/2012 8:40 AM, Tom Stellard wrote: > On Wed, Apr 18, 2012 at 11:18:05PM -0500, Sirish Pande wrote: >> Hi, >> >> Here's a patch for Hexagon Packetizer for review. This patch does >> not yield any warnings. >> > Would it be possible to split this

Krzysztof, Thanks for your interest to my questions. In order to clarify the context, here is the C source file of my test case. The 3 builtins initialize some stack pointers. They have to be executed before any other instruction. extern float fdivfaddfmul_a(float a, float b, float c, float d); volatile static float x1,x2,x3,x4; void _start(void) { float res;

On Fri, 2004-06-18 at 10:13, Chris Lattner wrote: > Module::gbegin/gend iterate over the global variables, and ::begin/end > iterate over the functions, some of which may be prototypes. This confused Vladimir and I remember it confusing me when I was reviewing LLVM core a few months ago. Would it be worthwhile to consider naming these globals_begin/globals_end and

On Fri, 18 Jun 2004, Reid Spencer wrote: > On Fri, 2004-06-18 at 10:13, Chris Lattner wrote: > > > Module::gbegin/gend iterate over the global variables, and ::begin/end > > iterate over the functions, some of which may be prototypes. > > This confused Vladimir and I remember it confusing me when I was > reviewing LLVM core a few months ago. Would it be worthwhile to