similar to: [LLVMdev] about switch and select instructions in SparcV9

Hi: When I tried to use llc -march=sparcv9 to compile some llvm .bc to SparcV9, I got such error: llc: /llvm/lib/Target/SparcV9/SparcV9RegInfo.h:62: virtual void llvm::TargetRegClassInfo::markColorsUsed(unsigned int, int, int, std::vector<bool, std::allocator<bool> >&) const: Assertion `UserRegType == RegTypeWanted && "Default method is probably incorrect for

Hi, I need to generate a branch instruction from within CodeGenIntrinsic in SparcV9BurgISel.cpp. I generate a few instructions and add them to the mvec vector, and then I need to generate a branch whose target is the first instruction in the vector. I've seen how other portions of the code do this, but they have access to more information than CodeGenIntrinsic. Thanks, Brent

LLVM build without big problems in obj dir == src dir case (for example, last night tester build) But I have problem with building CVS version LLVM in obj dir != src dir case. ======= Finished building ModuleMaker debug executable (without symbols) ======= gmake[2]: Leaving directory `/usr/home/wanderer/pkg/build/llvm/obj/examples/ModuleMaker' gmake[1]: Leaving directory

I resend email with updated (after mass header move) log examples. > LLVM build without big problems in obj dir == src dir case (for example, > last night tester build) > But I have problem with building CVS version LLVM in obj dir != src dir > case. > gmake[1]: Entering directory `/usr/home/wanderer/pkg/build/llvm/obj/projects' gmake[2]: Entering directory

Is there a way to access the current MachineBasicBlock info from within CodeGenIntrinsic in SparcV9BurgISel.cpp? The arguments are: Intrinsic::ID iid, CallInst &callInstr, TargetMachine &target, and std::vector<MachineInstr*>& mvec, none of which seem to offer access to the current MachineBasicBlock. Brent

Hi: I have extended the IR for adding flag. But I just want this flag to pass through the backend machine code. I know there're several passes like register relocation, schedualing, etc. But I think I just miss the part which is used to "parser" the LLVM IR to machine code instructions. Would you give me some help? Thank you ! > On Sun, 10 Jul 2005 shding at mtu.edu wrote:

Hi, I want to annotate values in llvm, like making a flag for the operands and result of an instruction for future use. I wonder if there's any interface to do such a thing? Thanks! -- Shuhan

Hi: I want to pass some message of instructions from LLVM Internal representation to backend code. For example, I make a flag for some certain operands of certain instructions. How can it be passed to the backend instructions? Which programs I should look into? Would someone give me some idea? Thank you ! -- Shuhan

Hi, Where can I find the main function of llvm compiler in the source file? Thanks! -- Shuhan

Hi, I'm changing bytecode format a little bit, i.e. for 2 operands Instructions, the original is like this: 01-00:Opcode type 07-02:Opcode 15-08: Instruction type 23-16: Operand#1 31-24: Operand#2 My change is like this: 01-00:Opcode type 07-02:Opcode 15-08: Instruction type 16: myflag1 17: myflag2 24-18: Operand#1 31-25: Operand#2 I do

Hi, In the directory of lib/CodeGen/SelectionDAG, I cann't find SelectionDAGISel.cpp. I only have DAGBuilder.cpp and SelectionDAG.cpp. I don't know why. My edtion is 1.4. Is it because of the edtion difference? Thanks! > On Mon, 11 Jul 2005 shding at mtu.edu wrote: >> I have extended the IR for adding flag. But I just want this flag to >> pass through the backend

As the title. Thank! -- Shuhan

Hi: For some reason, I changed the files /ByteCode/Writer/Writer.cpp and /ByteCode/Reader/Reader.cpp and I introduced an new version number 6. Now I replaced these two changed files with the original ones that are version 5. And I rebuild the llvm compiler. What make me mad is that the bytecode produced now is still version 6! Of course the reader cannot recognize it because the current reader

Thank you. I'm only consider about how the compiler comiles c program to LLVM IR. I know there should be a scanner, parser, and IR generator. But where is the main entrance and how about the flow of the process, especially about the IR generator? > shding at mtu.edu wrote: >> Hi, >> Where can I find the main function of llvm compiler in the source >> file? >>

Hi, I have some problems when I use this command: gcc hello.s -o hello.native(for example) to assembly the native language to a program. I always got a error message like this : "gccas: hello.s:3: parse error, unexpected $undefined. hello.s:3: while reading token: '.' " I don't know what's wrong here. By the way, when I learned llvm at the first time, I followed

I'm a new guy for llvm. I'm doing a project in which some instructions should be moved from one block into another. Those instructions may be data-dependent. When I tried to delete them one by one, it cause the error message like, " use stuck around after a def is destroyed" even if I deleted the use befor the def. When I tried to add them to another block, errors occurred like

On 03/02/2010, at 10:16 PM, Anton Korobeynikov wrote: > Hello, Nathan > >> I've put together some preliminary patches to add frontend support for the sparcv9-* subtarget (ie 64-bit SPARC), modelled on the corresponding x86-64 code - do these look reasonable for inclusion? This doesn't address the codegen side of things yet (isel falls over when trying to actually emit

Hi all, I've put together some preliminary patches to add frontend support for the sparcv9-* subtarget (ie 64-bit SPARC), modelled on the corresponding x86-64 code - do these look reasonable for inclusion? This doesn't address the codegen side of things yet (isel falls over when trying to actually emit 64-bit code), but at least bitcode generation looks correct now. Tested on

Hello, Nathan >   I've put together some preliminary patches to add frontend support for the sparcv9-* subtarget (ie 64-bit SPARC), modelled on the corresponding x86-64 code - do these look reasonable for inclusion? This doesn't address the codegen side of things yet (isel falls over when trying to actually emit 64-bit code), but at least bitcode generation looks correct now. Tested on

Hello, Nathan >   I may need to clarify, sparcv9-* is used for the SPARCV9 ABI (ie 64-bit ABI), rather than the SPARCV9 CPU per se. It serves the same purpose as x86_64-* and powerpc64-*, which is to say it's associated with -m64, not -mcpu=v9 (although unsurprisingly -m64 does require a V9 or later CPU). I may be wrong, but I think the only distinction in ARM is between arm and thumb