search for: globaladdress

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 node say i64 = GlobalAddress<0xHighLow> we want to convert it into i32 = GlobalAddress<0xLow>. [The belo...

...here'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 which will generate the address using values from two registers. We thought LUI and ADDI pair will be good to store the values in a i32 register. If we could transform GlobalAddress<0xHighLow> directly to GlobalAddress<0xLow>, w...

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

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 couldn't find much about it in the PowerPC implementation either. The only thing is in the ctor...

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

...t; t9, t7, > t12, undef:i64 > t7: v64i32 = add t6, t4 > t6: v64i32,ch = load<LD256[bitcast ([65 x i32]* @c to <64 x > i32>*)](align=16)(tbaa=<0x30c5438>)(dereferenceable)> t0, t14, > undef:i64 > t14: i64 = X86ISD::Wrapper TargetGlobalAddress:i64<[65 x > i32]* @c> 0 > t13: i64 = TargetGlobalAddress<[65 x i32]* @c> 0 > t3: i64 = undef > t4: v64i32,ch = load<LD256[bitcast ([65 x i32]* @b to <64 x > i32>*)](align=16)(tbaa=<0x30c5438>)(dereferenceable)> t0, t...

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

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

...t5: ch = llvm.clp.set.rspb t3, TargetConstant:i16<393>, Constant:i32<64> t8: ch = llvm.clp.set.rspsu t5, TargetConstant:i16<394>, Constant:i32<8> t13: ch = store<Volatile ST4[@x1](tbaa=<0x3dbe418>)> t8, ConstantFP:f32<1.000000e+00>, GlobalAddress:i16<float* @x1> 0, undef:i16 t16: ch = store<Volatile ST4[@x2](tbaa=<0x3dbe418>)> t13, ConstantFP:f32<2.000000e+00>, GlobalAddress:i16<float* @x2> 0, undef:i16 t19: ch = store<Volatile ST4[@x3](tbaa=<0x3dbe418>)> t16, ConstantFP:f32<3.00000...

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 file, is this right? If you aren't using 64-bit pointers, you should investigate where this node came from. > I guess it is expecting that GlobalAddress be legalized be...

...full 64-bit > pointer you'd need 4 instructions: > > lui rLO32, addr:MO_LO32_LO > addi rLO32, rLO32, addr:MO_LO32_HI > lui rHI32, addr:MO_HI32_LO > addi rHI32, rLO32, addr:MO_LO32_HI > > or some variation for PIC etc. > > > If we could transform GlobalAddress<0xHighLow> directly to > GlobalAddress<0xLow>, we could use the present RISCVII::MO_HI and MO_LO as > they only exact the 32 high bits. What do you think? > > I still recommend against reusing GlobalAddress as-is with an i32 > type, but that's probably a minor detail....

...t;0x30c5438>)> t9, t7, t12, undef:i64 >> t7: v64i32 = add t6, t4 >> t6: v64i32,ch = load<LD256[bitcast ([65 x i32]* @c to <64 x >> i32>*)](align=16)(tbaa=<0x30c5438>)(dereferenceable)> t0, t14, undef:i64 >> t14: i64 = X86ISD::Wrapper TargetGlobalAddress:i64<[65 x i32]* @c> 0 >> t13: i64 = TargetGlobalAddress<[65 x i32]* @c> 0 >> t3: i64 = undef >> t4: v64i32,ch = load<LD256[bitcast ([65 x i32]* @b to <64 x >> i32>*)](align=16)(tbaa=<0x30c5438>)(dereferenceable)> t0, t16, undef...

...rgetConstant:i16<393>, Constant:i32<64> > >             t8: ch = llvm.clp.set.rspsu t5, TargetConstant:i16<394>, > Constant:i32<8> > >           t13: ch = store<Volatile ST4[@x1](tbaa=<0x3dbe418>)> t8, > ConstantFP:f32<1.000000e+00>, GlobalAddress:i16<float* @x1> 0, undef:i16 > >         t16: ch = store<Volatile ST4[@x2](tbaa=<0x3dbe418>)> t13, > ConstantFP:f32<2.000000e+00>, GlobalAddress:i16<float* @x2> 0, undef:i16 > >       t19: ch = store<Volatile ST4[@x3](tbaa=<0x3dbe418>)>...

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

...e: [LLVMdev] New to LLVM, Help needed 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 file, is this right? If you aren't using 64-bit pointers, you should investigate where this node came from. > I guess it is expecting that GlobalAddress be legalized be...

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

..., >> s11_3ImmPred:$offset)))]>; >> >> let mayLoad = 1, neverHasSideEffects = 1 in >> -def LDrid_GP : LDInst<(outs DoubleRegs:$dst), >> +def LDrid_GP : LDInst2<(outs DoubleRegs:$dst), >> (ins globaladdress:$global, u16Imm:$offset), >> "$dst=memd(#$global+$offset)", >> []>; >> >> let mayLoad = 1, neverHasSideEffects = 1 in >> -def LDd_GP : LDInst<(outs DoubleRegs:$dst), >> +def LDd_GP : LDInst2<(outs DoubleRegs:$dst),...

...nstant:i16<393>, > Constant:i32<64> > >             t8: ch = llvm.clp.set.rspsu t5, TargetConstant:i16<394>, > Constant:i32<8> > >           t13: ch = store<Volatile ST4[@x1](tbaa=<0x3dbe418>)> t8, > ConstantFP:f32<1.000000e+00>, GlobalAddress:i16<float* @x1> 0, > undef:i16 > >         t16: ch = store<Volatile ST4[@x2](tbaa=<0x3dbe418>)> t13, > ConstantFP:f32<2.000000e+00>, GlobalAddress:i16<float* @x2> 0, > undef:i16 > >       t19: ch = store<Volatile ST4[@x3](tbaa=<0x3dbe4...

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