similar to: [LLVMdev] Load with null memory operand?

It depends on how your target models its addressing mode. Targets with complex addressing modes usually isel addresses with custom code. Evan On Mar 6, 2009, at 4:05 PM, Villmow, Micah wrote: > How do I match against this instruction? > 01ABDA58: i64,ch = load 01ABD948, 01ABD8C0, 01AB1350 <null:0> > > > This is the first time I’ve seen NULL in the memory operand >

It seems that LLVM is converting all the 16 bit ints into 32 bit ints. Is there a way I can tell LLVM that 16 bit ints are valid and legal and not to do any conversions on them? Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. S1-609 One AMD Place Sunnyvale, CA. 94085 P: 408-749-3966 -------------- next part

I'm hitting an issue where legalizeOp is overflowing the stack. Are there any recommended ways of getting around this? The bitcode that causes this issue is attached. Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. S1-609 One AMD Place Sunnyvale, CA. 94085 P: 408-749-3966 -------------- next part -------------- An

Are you marking i16 a legal type? In XXISelLowering.cpp, you should assign it a register class. e.g. addRegisterClass(MVT::i16, XX::i16RegisterClass) Evan On Feb 2, 2009, at 12:19 PM, Villmow, Micah wrote: > It seems that LLVM is converting all the 16 bit ints into 32 bit > ints. Is there a way I can tell LLVM that 16 bit ints are valid and > legal and not to do any conversions

Are you running with restricted stack size, e.g. in a pthread process? Evan On Mar 10, 2009, at 5:16 PM, Villmow, Micah wrote: > I’m hitting an issue where legalizeOp is overflowing the stack. Are > there any recommended ways of getting around this? > > The bitcode that causes this issue is attached. > > Thanks, > Micah Villmow > Systems Engineer > Advanced

What is the difference between these two functions? The header file for TargetLowering class says that LowerArguments must be implemented, but only the Sparc and IA64 backends implement them. X86, PowerPC and CellSPU implement LowerFORMAL_ARGUMENTS, but I can find a setOperationAction that states that they should be lowered. Can someone please explain this for me? Thanks, Micah Villmow

Currently with my understanding of using callingconv.td I still need to lower three functions, FORMAL_ARGUMENTS, CALL, and RET. Is there any known way to have LLVM automagically generate code from tablegen without having to custom lower these functions? The reasoning for this is that all registers are virtual in my backend and I have specified for llvm to use it's generic dynamic stack

I have a pass that modifies my machine dependent instructions and I have ran into a situation where I want to remove all instructions that an instruction is dependent on when I remove an instruction. Is there a way to do this using the API calls? For example, I have a sequence of instructions a = b + c d = c * c store d, *a load e, *a f = e + d since the store and load are

I need to support 16 bit floats for some operations, outside of datatypes.td and the constants class, is there anything else I will need to modify to add f16 support? Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. S1-609 One AMD Place Sunnyvale, CA. 94085 P: 408-749-3966 -------------- next part -------------- An HTML

I am running into an issue where if I have multiple functions compiled in the same compilation unit the stack offset is not starting at zero. For example: func1(...) { ... } func2(...) { ... } Say the first function uses 64 bytes of the stack and an assumed offset of 0 and the second function uses 32 bytes of the stack but an assumed offset of 64. I've found out how to get the

I've patched valuetypes.td/h to add data types that my backend needs to support. There seems to be a lot of assumptions made in other spots of the code that limit the number of data types to 32. I need to add a few more types, but once I go over this limit llvm starts acting wonky. I found all the items that are hard coded to 32 and a section that isn't, but I cannot figure out how to

Is there a way to force llvm to promote all smaller types to i32 instead of i16? Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. S1-609 One AMD Place Sunnyvale, CA. 94085 P: 408-749-3966 -------------- next part -------------- An HTML attachment was scrubbed... URL:

Is there a way to define a multi-class pattern in tablegen? Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. S1-609 One AMD Place Sunnyvale, CA. 94085 P: 408-749-3966 -------------- next part -------------- An HTML attachment was scrubbed... URL:

I am hitting this assertion: assert(I != VRBaseMap.end() && "Node emitted out of order - late"); I am not sure why this assertion is being triggered or what I changed that is causing it. This is asserting when SDValue is FrameIndexSDNode 1. I don't have any code that modified frameindices until my overloaded RegisterInfo function. I've attached the bc file.

I have a very simple kernel that exposes a bug in the backend I am working on and I cannot figure out how to fix the problem. I've narrowed down the issue to be with dynamic stack allocation. The problem I am having is that if I declare a variable inside of the loop, the code that my backend generates produces incorrect results; however, if I move this declaration outside of the loop the

I have the following function: define void @test_fc_0_kernel(i16 signext %x, i16 signext %y, i16 addrspace(11)* %input, i32 addrspace(11)* %result) { entry: %call = tail call i32 @get_id(i32 0) ; <i32> [#uses=2] %cmp = icmp slt i16 %x, %y ; <i1> [#uses=1] br i1 %cmp, label %if.then, label %if.end

I'm still trying to track down some alignment issues with loads(i.e. 8/16 bit loads being turned into 32bit sign extending loads) and I cannot for the life of me seem to figure out how to enter this section of code: // If this is an unaligned load and the target doesn't support it, // expand it. if (!TLI.allowsUnalignedMemoryAccesses()) { unsigned

----- Original Message ----- From: Villmow, Micah To: LLVM Developers Mailing List Sent: Friday, February 06, 2009 5:47 AM Subject: [LLVMdev] 16 bit floats I need to support 16 bit floats for some operations, outside of datatypes.td and the constants class, is there anything else I will need to modify to add f16 support? probably also code generation (can't give specifics, no

This isn't running in a child process, but this is a win32 machine. The problem I'm having is LegalizeOp is recursively calling itself 6 times, followed by 3 calls to ExpandEXTRACT_VECTOR_ELT, with each LegalizeOp pushing 20KBof data onto the stack and Expand pushing 800B of data on the stack. So that is 9 function calls pushing ~140KB of data onto the stack. This set of 9 function

Hello Villmow, Is it your backend EFI Byte Code Virtual Machine?? Would you mind to give me an example about what pseudo instruction you add?? thanks a lot yi-hong 2011/1/19 Villmow, Micah <Micah.Villmow at amd.com> > I have this same problem in our backend. I solve it by adding a pseudo > instruction at instruction selection that transforms @R1 into R1, so only a > single