similar to: [LLVMdev] Lowering operations to 8-bit!

On Wed, 26 Sep 2007 Alireza.Moshtaghi at microchip.com wrote: > I am trying to lower all llvm operations to 8-bit. So far I was trying > to have llvm do all that for me using things like: ok > setOperationAction(ISD::ADD, MVT::ii,Promote); > setOperationAction(ISD::ADD, MVT::i8,Legal); > setOperationAction(ISD::ADD, MVT::i16,Expand); > setOperationAction(ISD::ADD,

I'm working on version 2.0 The assertion at line 2380 of LegalizeDAG.cpp fails when it is trying to lower the add with i16. assertion reads: assert(MVT::isVector(Node->getValueType(0)) && "Cannot expand this binary operation!"); I am trying to compile a very simple program as follows: short var; void foo(void) { Var++; } The input bytecode, (in addition to the

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

Thank you Chris, I had the pointer size wrong. I fixed it and now it passes that point as expected :) which takes me to a second question: The processor that I am working on is 8-bit and has Harvard architecture; this implies different pointer types (sizes) to objects in data memory or program memory (functions or data in program memory) At this moment, I am just using only one pointer size

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

On Sep 27, 2007, at 4:35 PM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com> wrote: > I'm working on version 2.0 > The assertion at line 2380 of LegalizeDAG.cpp fails when it is > trying to > lower the add with i16. > > assertion reads: > assert(MVT::isVector(Node->getValueType(0)) && > "Cannot expand this

Hi, I have started to write an llvm backend for one of our microcontrollers (PICxx). I started studying the framework of PowerPc backend of llvm and decided to start by following that framework. Now I have most of the classes and Tblgen files written for a very basic hypothetical microcontroller with very few instructions. The project builds and the llc recognizes the new processor, however,

I moved my code to 2.1 but still the same. If I make ADD i16 legal, then it goes through, but it has problem expanding it to i8. Should I go ahead and customize it and do the same for all instructions? Or there is a more general thing that I can do? A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent:

On Wed, 12 Sep 2007 Alireza.Moshtaghi at microchip.com wrote: > Thank you Chris, > I had the pointer size wrong. I fixed it and now it passes that point as > expected :) which takes me to a second question: cool > The processor that I am working on is 8-bit and has Harvard > architecture; this implies different pointer types (sizes) to objects in > data memory or program memory

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

Chris, Extending LLVM IR to support PointerTypes that take an address space is what I was hoping to avoid. However, if we want to do things right, that is probably the way to go. Now that we got here, let me write some of my thoughts on this and solicit your input: --- 1) Syntax extension: In our existing compiler for 8-bit microcontrollers, we have introduced rom and ram qualifiers (with ram

Please do a debug build and run it under gdb. Let us know where it is asserting and what it is asserting on so we can help you. Evan On Sep 7, 2007, at 4:50 PM, Alireza.Moshtaghi at microchip.com wrote: > Hi, > I have started to write an llvm backend for one of our > microcontrollers (PICxx). I started studying the framework of > PowerPc backend of llvm and decided to start by

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

I am trying to verify the generated DAG after converting from llvm to DAG, however I'm not sure if this is correct or not. Here is the situation: In order to get LLVM to lower to 8-bit I have to define only 8-bit registers and the pointer size also to be 8-bit. Doing so, the attached DAG is generated for a load:i16. I have problem understanding this DAG in two places: 1)As you can see the

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

On Sep 28, 2007, at 11:36 AM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com> wrote: > I moved my code to 2.1 but still the same. > If I make ADD i16 legal, then it goes through, but it has problem > expanding it to i8. > Should I go ahead and customize it and do the same for all > instructions? > Or there is a more general thing that I

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); AddPromotedToType(ISD::STORE, MVT::f32, MVT::i32); setOperationAction(ISD::LOAD, MVT::f32, Promote);

Thank you Evan, I added the return Type::Int8Ty to the switch statement to get it to work. I don't know if this can have other consequences, I haven't yet verified if the generated Legalized DAG is correct though. A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Monday, October 01, 2007 3:23 PM To:

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