search for: globaladdress

Displaying 20 results from an estimated 95 matches for "globaladdress".

2019 Jul 09
2
Manipulating global address inside GlobalAddress SDNode in (RISCV) LLVM backend
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...
2019 Jul 11
2
Manipulating global address inside GlobalAddress SDNode in (RISCV) LLVM backend
...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...
2018 May 16
0
GlobalAddress lowering strategy
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...
2007 Sep 11
2
[LLVMdev] New to LLVM, Help needed
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...
2008 Aug 06
3
[LLVMdev] Modeling 16-bit pointer registers for an 8-bit target
...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...
2017 Jul 07
2
Error in v64i32 type in x86 backend
...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...
2008 Aug 07
2
[LLVMdev] Modeling 16-bit pointer registers for an 8-bit target
> > 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...
2009 Apr 28
1
[LLVMdev] AddressSpace of a GlobalAddress
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
2018 May 04
0
How to constraint instructions reordering from patterns?
...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...
2007 Sep 12
0
[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...
2019 Jul 11
2
Manipulating global address inside GlobalAddress SDNode in (RISCV) LLVM backend
...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....
2017 Jul 07
2
Error in v64i32 type in x86 backend
...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...
2018 May 04
2
How to constraint instructions reordering from patterns?
...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>)>...
2018 May 04
2
How to constraint instructions reordering from patterns?
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
2007 Sep 12
2
[LLVMdev] New to LLVM, Help needed
...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...
2008 Aug 06
0
[LLVMdev] Modeling 16-bit pointer registers for an 8-bit target
...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...
2012 Apr 19
0
[LLVMdev] Target Dependent Hexagon Packetizer patch
..., >> 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),...
2018 May 04
0
How to constraint instructions reordering from patterns?
...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...
2004 Jun 19
2
[LLVMdev] MachineOperand: GlobalAddress vs. ExternalSymbol
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
2004 Jun 19
0
[LLVMdev] MachineOperand: GlobalAddress vs. ExternalSymbol
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