similar to: [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

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

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

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

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

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

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:

On Oct 3, 2007, at 3:21 PM, Alireza.Moshtaghi at microchip.com wrote: > 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. If this works, please submit a patch. Otherwise please submit a bug

On Oct 8, 2007, at 3:15 PM, Alireza.Moshtaghi at microchip.com wrote: > 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

Evan, The machine is 8 bit, and of course all registers are 8-bit too. Memory access on this machine is a bit different. The memory is banked into banks of 256-byte, and you can select the active bank using a bank select register. All instructions can access the memory with an 8-bit operand, so in that sense the address space can be viewed as 256-byte long. On the other hand, there are three

ExpandOp is not called at all. In SelectionDAGLegalize::HandleOp() only the ValueType is considered in the switch statement to decide if it is legal or promote or expand. As I trace back (correct me if I'm wrong) these values are set in TargetLowering::computeRegisterProperties() and it is based on the largest register class (in my case the smallest possible pointer size, 16-bit) So it reduces

Attached please find the gdb backtrace dump and the postscript file of the DAG right before assertion. The red Node is the current Node in LegalizeOp() The only thing that I am customizing before we get here is the FORMAL_ARGUMENTS. At this time I don't really care about the arguments, just want to get some global values working. When I trace the program, it is well passed the legalizing of

So does that mean that LLVM can't lower automatically to 8-bit values? I tried defining 8-bit pointers in the subtarget using "p:8:8:8" but it asserts at line 566 of TargetData.cpp in the default case of TargetData::getIntPtrType() Is it difficult to add 8-bit support? A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On

On Sep 28, 2007, at 1:10 PM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com> wrote: > Attached please find the gdb backtrace dump and the postscript file of > the DAG right before assertion. > The red Node is the current Node in LegalizeOp() Okay, this is the problem. LegalizeOp should only be called on a node if the VT is valid for the target.

On Oct 1, 2007, at 11:33 AM, Alireza.Moshtaghi at microchip.com wrote: > So does that mean that LLVM can't lower automatically to 8-bit values? There is no inherent reason. LLVM should be able to lower to 8-bit values. It's probably a bug somewhere. In TargetLowering.h: bool isTypeLegal(MVT::ValueType VT) const { return !MVT::isExtendedVT(VT) && RegClassForVT[VT] !=

On Sep 28, 2007, at 4:53 PM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com> wrote: > ExpandOp is not called at all. > In SelectionDAGLegalize::HandleOp() only the ValueType is > considered in > the switch statement to decide if it is legal or promote or expand. > As I trace back (correct me if I'm wrong) these values are set in >

Thank you Chris and Christopher, I agree... the Embedded C Language Extensions report provides a good foundation to build on, and what it proposes as far as Address Space is probably a super set of what we have in our existing compiler (and probably would like to keep) so no conflict there. I also agree that regardless of how we would like to deal with pointers, the same extensions must be applied

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

Hi, I am trying to use the viewGraph() method of SelectionDAG, of course I installed graghviz, nuked my build directory, reconfigured and rebuilt the project. However, gdb does not consistently recognize SelectionDAG::viewgraph(), some times it finds it and some times it says that llvm::SelectionDAG does not have viewGraph(). It worked for couple of instances when I was in my modules but when for