search for: expandintegeroperand

...st email is here. > > > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon- > 20081013/068667.html > > thanks, I remember now (more or less). So would something like > ReplaceNodeResults > solve the problem? > Well the magnitude of the task is not small. ExpandIntegerOperand() calls LowerOperation() to allow targets to handle illegal operands. So we will need to change the interface of LowerOperation() to pass an extra argument called Results, which is an array of SDValue. Targets will push the result values in this array and then we can replace values in ExpandInteger...

Hi Sanjiv, > Well the magnitude of the task is not small. > ExpandIntegerOperand() calls LowerOperation() to allow targets to handle > illegal operands. So we will need to change the interface of > LowerOperation() to pass an extra argument called Results, which is an > array of SDValue. Targets will push the result values in this array and > then we can replace val...

All the sub methods called inside ExpandIntegerOperand like ExpandInOp_STORE etc have access to the expanded operands map. Why they aren't passed to target LowerOperation? A target may also want to use the already expanded Lo and Hi parts. - Sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL: <http:...

Hi Duncan, We are targetting a reasonably functional PIC16 backend for llvm 2.5. The only problem in our way is a local patch in ExpandIntegerOperand, which couldn't make its way to trunk so far. The discussion is contained in the following link: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081103/069593.html I now have time to take it up again and do whatever rework is required. I saw that you have made some changes in...

...ds [mailto:baldrick at free.fr] Sent: Thu 1/8/2009 8:41 PM To: Sanjiv Kumar Gupta - I00171 Cc: llvmdev at cs.uiuc.edu Subject: Re: PIC16 backend for llvm 2.5 Hi Sanjiv, > We are targetting a reasonably functional PIC16 backend for llvm 2.5. > The only problem in our way is a local patch in ExpandIntegerOperand, which couldn't make its way to trunk so far. The discussion is contained in the following link: > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081103/069593.html > > I now have time to take it up again and do whatever rework is required. I saw that you have ma...

On Tue, Sep 30, 2008 at 9:48 AM, <Sanjiv.Gupta at microchip.com> wrote: > All the sub methods called inside ExpandIntegerOperand like ExpandInOp_STORE > etc have access to the expanded operands map. > > Why they aren't passed to target LowerOperation? A target may also want to > use the already expanded Lo and Hi parts. You don't really need access to the map; just use build an EXTRACT_ELEMENT node, and...

Hi Sanjiv, > We are targetting a reasonably functional PIC16 backend for llvm 2.5. > The only problem in our way is a local patch in ExpandIntegerOperand, which couldn't make its way to trunk so far. The discussion is contained in the following link: > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081103/069593.html > > I now have time to take it up again and do whatever rework is required. I saw that you have ma...

Hi Sanjiv, > Well, the first email is here. > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081013/068667.html thanks, I remember now (more or less). So would something like ReplaceNodeResults solve the problem? Ciao, Duncan.

Hi All, I have some doubt in LLVM Type Legalizer. How will LOAD:i8 with an i16 operand be lowered in type legalizer? (i16 type is not legal for our target) Following assertion in function ExpandIntegerOperand (file LegalizeIntegerTypes.cpp) is not allowing us to change LOAD node. assert(Res.getValueType() == N->getValueType(0) && N->getNumValues() == 1 && "Invalid operand expansion"); LOAD node has two values but the assertion checks N->getNumValues() == 1 whi...

On Fri, 2009-01-16 at 10:03 +0100, Duncan Sands wrote: > Hi Sanjiv, > > > Well the magnitude of the task is not small. > > ExpandIntegerOperand() calls LowerOperation() to allow targets to handle > > illegal operands. So we will need to change the interface of > > LowerOperation() to pass an extra argument called Results, which is an > > array of SDValue. Targets will push the result values in this array and > > the...

...rOperationWrapper(llvm::SDNode*, llvm::SmallVectorImpl<llvm::SDValue>&, llvm::SelectionDAG&) const + 27 11 clang 0x00000001008d63e4 llvm::DAGTypeLegalizer::CustomLowerNode(llvm::SDNode*, llvm::EVT, bool) + 164 12 clang 0x00000001008cd718 llvm::DAGTypeLegalizer::ExpandIntegerOperand(llvm::SDNode*, unsigned int) + 280 13 clang 0x00000001008d290f llvm::DAGTypeLegalizer::run() + 991 14 clang 0x00000001008d87b8 llvm::SelectionDAG::LegalizeTypes() + 40 15 clang 0x0000000100981f88 llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 1192 16 clang...

...Wrapper(llvm::SDNode*, llvm::SmallVectorImpl<llvm::SDValue>&, llvm::SelectionDAG&) const + 27 > 11 clang 0x00000001008d63e4 llvm::DAGTypeLegalizer::CustomLowerNode(llvm::SDNode*, llvm::EVT, bool) + 164 > 12 clang 0x00000001008cd718 llvm::DAGTypeLegalizer::ExpandIntegerOperand(llvm::SDNode*, unsigned int) + 280 > 13 clang 0x00000001008d290f llvm::DAGTypeLegalizer::run() + 991 > 14 clang 0x00000001008d87b8 llvm::SelectionDAG::LegalizeTypes() + 40 > 15 clang 0x0000000100981f88 llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 1192 &...

...D:i8 with an i16 operand" mean? Are you saying that the type of a pointer is i16, and you are loading an i8 value from the pointed to location? If so, you are in trouble because many parts of the code generator assume that the type of a pointer is legal. > Following assertion in function ExpandIntegerOperand (file > LegalizeIntegerTypes.cpp) is not allowing us to change LOAD node. > > > > assert(Res.getValueType() == N->getValueType(0) && N->getNumValues() == > 1 && "Invalid operand expansion"); > > > > LOAD node has two values but...

> > On Tue, Sep 30, 2008 at 9:48 AM, <Sanjiv.Gupta at microchip.com> wrote: > > All the sub methods called inside ExpandIntegerOperand like > ExpandInOp_STORE > > etc have access to the expanded operands map. > > > > Why they aren't passed to target LowerOperation? A target may also want > to > > use the already expanded Lo and Hi parts. > > You don't really need access to the map; just...