similar to: [LLVMdev] Promote MVT::f32 load/store to MVT::i32 cause infinite loop in LegalizeDAG?

On Mon, Aug 5, 2013 at 2:25 PM, Tom Stellard <tom at stellard.net> wrote: > On Mon, Aug 05, 2013 at 02:09:58PM -0400, Francois Pichet wrote: > > On my target store/load of f32 or i32 are equivalents. > > Previously I had duplicate instructions def in .td to map f32 and i32 to > > the same opcode. > > > > I deleted all that and I instead tried a new approach

On Mon, Aug 05, 2013 at 02:09:58PM -0400, Francois Pichet wrote: > On my target store/load of f32 or i32 are equivalents. > Previously I had duplicate instructions def in .td to map f32 and i32 to > the same opcode. > > I deleted all that and I instead tried a new approach (to simplify things) : > > setOperationAction(ISD::STORE, MVT::f32, Promote); >

The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems currently has a problem handling integer types smaller than 64 bits. This is because the ABI specifies that these types are zero-extended to 64 bits on the stack and the default logic provided in LegalizeDAG does not use that convention. Specifically, for these targets we have: setOperationAction(ISD::VAARG, MVT::Other, Expand);

On Fri, 23 Mar 2012 09:50:12 +0100 Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Finkel, > > Le 23/03/2012 05:50, Hal Finkel a écrit : > > The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems > > currently has a problem handling integer types smaller than 64 bits. > > This is because the ABI specifies that these types are > > zero-extended

Hi Finkel, Le 23/03/2012 05:50, Hal Finkel a écrit : > The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems > currently has a problem handling integer types smaller than 64 bits. > This is because the ABI specifies that these types are zero-extended to > 64 bits on the stack and the default logic provided in LegalizeDAG does > not use that convention. Specifically, for

Le 23/03/2012 17:02, Hal Finkel a écrit : > On Fri, 23 Mar 2012 09:50:12 +0100 > Ivan Llopard<ivanllopard at gmail.com> wrote: > >> Hi Finkel, >> >> Le 23/03/2012 05:50, Hal Finkel a écrit : >>> The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems >>> currently has a problem handling integer types smaller than 64 bits. >>> This

Thanks, indeed it was on the LegalizeDAG.cpp and the information proved very useful. I also realized that the customization, promotion or expansion will occur whenever any operand, with the same type as the type specified on the second argument (MVT) of setOperationAction function, appears. (Correct me if I'm wrong). The second doubt I have regards instruction matching. When I define a

On Feb 12, 2007, at 1:41 AM, Christopher Lamb wrote: > > selector refused to select certain ops (specifically stores) for some > instructions when the operand type wasn't the first type for the > register class. After some digging around I seem to have solved the > problem by creating bitconvert patterns between the types in the > register class like the following: > >

Sorry, glad I'm in the right place. Before I start, I want to state that I'm a beginer and I'm trying to develop a backend by adapting an existent target to my platform. My first doubt is about the SelectionDAG and the TargetLowering class. When I use, for example: setOperationAction(ISD::ADD, MVT::i1, Promote); Is it correct to say that I'm promoting any operand used by the

Hi All, I'm working on a back end for an architecture that makes use of multi- typed register classes. def MR: RegisterClass<"namespace", [type1, type2, ... ], ... > When running some preliminary tests I found that the instruction selector refused to select certain ops (specifically stores) for some instructions when the operand type wasn't the first type for the

On Mon, Jun 6, 2016 at 8:32 AM, Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > It is not a keyword. It is a node defined in > include/llvm/Target/TargetSelectionDAG.td. You can likely find most of the > definitions you're wondering about there. > In terms of its purpose, perhaps someone can elaborate on that a bit more, > but there is no corresponding

Thanks, for insight, Eli, So instead of setOperationAction(ISD::STORE, MVT::i1, Expand); one should probably do setOperationAction(ISD::STORE, MVT::i1, Custom); and implement it in NVPTXTargetLowering::LowerOperation. But this issue makes a good point about the code efficiency: I suspect such expansion will be very ugly in terms of performance. Probably we can do much better if bool would use

On Fri, Jun 29, 2012 at 2:11 PM, Dmitry N. Mikushin <maemarcus at gmail.com> wrote: > Hi again, > > Kind people on #llvm helped me to utilize bugpoint to reduce the > previously submitted test case. For record, it code be done with the > following command: > > $ bugpoint -llc-safe test.ll > > The resulting IR is attached, and it is crashing in the same way. Is >

Hello Sebastien, Thank you very much for the clarification. This would greatly help us in our development. I have noticed that setOperationAction(Expand) does not always work, for these cases, does it automatically mean that setOperationAction(Custom) should be used or not necessarily? Currently, we perform a pseudo instruction instead of setting it to custom. For example in the case of a

Hi Duncan, > did you declare i1 to be an illegal type? No. How? 2012/6/30 Duncan Sands <baldrick at free.fr>: > Hi Dmitry, >> So instead of setOperationAction(ISD::STORE, MVT::i1, Expand); one >> should probably do setOperationAction(ISD::STORE, MVT::i1, Custom); >> and implement it in NVPTXTargetLowering::LowerOperation. >> >> But this issue makes a

Hi Dmitry, > So instead of setOperationAction(ISD::STORE, MVT::i1, Expand); one > should probably do setOperationAction(ISD::STORE, MVT::i1, Custom); > and implement it in NVPTXTargetLowering::LowerOperation. > > But this issue makes a good point about the code efficiency: I suspect > such expansion will be very ugly in terms of performance. Probably we > can do much better if

In http://reviews.llvm.org/D8713, I added the 64bit integer store ("std") and load ("ldd") instructions for 32bit sparc. But now I need codegen to know how to emit them, and am not sure the best way to go about teaching the backend that 64bit integers can be used natively, but only for loads and stores. (I originally wrote an earlier draft of question in the review but it

Hi Duncan, Sorry I don't understand your point, could you please explain a little bit more? Why i1 should be declared illegal? Operations on byte-wide types like char or bool are pretty legal, according to PTX spec: "Registers may be typed (signed integer, unsigned integer, floating point, predicate) or untyped. Register size is restricted; aside from predicate registers which are

In our (NVIDIA's) NVVM IR spec, we define i1 having a memory size of 8 bit. setOperationAction(ISD::LOAD, MVT::i1, Custom); setOperationAction(ISD::STORE, MVT::i1, Custom); is the right way to go. Yuan From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Justin Holewinski Sent: Monday, July 02, 2012 9:55 AM To: Dmitry N. Mikushin Cc: llvmdev at

Hi Dmitry, >> did you declare i1 to be an illegal type? > > No. How? I think it will be considered illegal if you don't add it to any register class. Ciao, Duncan. > > 2012/6/30 Duncan Sands <baldrick at free.fr>: >> Hi Dmitry, >>> So instead of setOperationAction(ISD::STORE, MVT::i1, Expand); one >>> should probably do