search for: visitbitcast

...s, I'm trying to hoist GlobalValues that are used many times. A new pass hides each hoisted GV behind a BITCAST in the dominating BB. The pass then updates users with the output of the BITCAST. This pass works properly AFAICT. The problems come in instruction selection. SelectionDAGBuilder::visitBitCast() treats the BITCAST as a no-op and eventually users of the GV fold the relocation as if hoisting never happened. Experiments turning the BITCAST into a copytoreg failed and anyway I feel like I'm just shooting in the dark. Can anyone can suggest a strategy for lowering a hoisted GV? The end...

...new pass hides each > > hoisted > > GV behind a BITCAST in the dominating BB. The pass then updates > > users > > with the output of the BITCAST. This pass works properly AFAICT. > > > > The problems come in instruction selection. > > SelectionDAGBuilder::visitBitCast() treats the BITCAST as a no-op > > and > > eventually users of the GV fold the relocation as if hoisting never > > happened. Experiments turning the BITCAST into a copytoreg failed > > and > > anyway I feel like I'm just shooting in the dark. > > > >...

...vel movl. > > Until we can generate correct code from IR containing address spaces, discussion of how to optimise this IR seems premature. I've done a quick test: the problem is that the BITCAST node is not generated during the SelectionDAG building. If you look in SelectionDAGBuilder::visitBitCast, you will see that the node is generated only if the operand value of the bitcast operation and the result value have different EVTs: the address space information is not handled in EVT and so pointers in different address spaces are mapped to the same EVT that imply a missing BITCAST node. Ma...

...rate correct code from IR containing address spaces, >> discussion of how to optimise this IR seems premature. >> > > I've done a quick test: the problem is that the BITCAST node is not > generated during the SelectionDAG building. If you look in > SelectionDAGBuilder::**visitBitCast, you will see that the node is > generated only if the operand value of the bitcast operation and the result > value have different EVTs: the address space information is not handled in > EVT and so pointers in different address spaces are mapped to the same EVT > that imply a missing B...

...gt;getAddressSpace()); + ReplaceWith = InsertBitCastBefore(NewInst, GEPTy, *GEP); + } + ReplaceInstUsesWith(*OldInst, ReplaceWith); + EraseInstFromFunction(*OldInst); + + } + + // Return the old instruction, so it can be removed. + return &CI; +} + Instruction *InstCombiner::visitBitCast(BitCastInst &CI) { // If the operands are integer typed then apply the integer transforms, // otherwise just apply the common ones. @@ -7873,7 +7950,9 @@ // If the address spaces don't match, don't eliminate the bitcast, which is // required for changing types. if (...

On 8 Aug 2013, at 04:23, Pete Cooper <peter_cooper at apple.com> wrote: > > On Aug 7, 2013, at 7:23 PM, Michele Scandale <michele.scandale at gmail.com> wrote: > >> On 08/08/2013 03:52 AM, Pete Cooper wrote: >> >> From here I understand that in the IR there are addrspace(N) where N=0,1,2,3,... according to the target independent mapping done by the

...tCastBefore(NewInst, GEPTy, *GEP); > + } > + ReplaceInstUsesWith(*OldInst, ReplaceWith); > + EraseInstFromFunction(*OldInst); > + > + } > + > + // Return the old instruction, so it can be removed. > + return &CI; > +} > + > Instruction *InstCombiner::visitBitCast(BitCastInst &CI) { > // If the operands are integer typed then apply the integer > transforms, > // otherwise just apply the common ones. > @@ -7873,7 +7950,9 @@ > // If the address spaces don't match, don't eliminate the > bitcast, which is > // req...

Hi Eli, Mon Ping, > In ISO/IEC WG14 n1169 on the C extensions to support embedded > processors, any two address spaces must be disjoint, must be > equivalent, or must be nested. Ah, that standard is a lot clearer on this subject than the DSP-C one I read was. > As Eli indicated, the actual relationship is platform specific depending on > what makes the most sense for

In ISO/IEC WG14 n1169 on the C extensions to support embedded processors, any two address spaces must be disjoint, must be equivalent, or must be nested. As Eli indicated, the actual relationship is platform specific depending on what makes the most sense for your hardware and how the program will behave will depend on that relationship. -- Mon Ping On Jul 17, 2008, at 7:25 AM, Eli

On Aug 7, 2013, at 7:23 PM, Michele Scandale <michele.scandale at gmail.com> wrote: > On 08/08/2013 03:52 AM, Pete Cooper wrote: >>> Why a backend should be responsible (meaning have knowledge) for a >>> mapping between high level address spaces and low level address spaces? >> Thats true. I’m thinking entirely from the persecutive of the backend >> doing