similar to: [LLVMdev] 16 bit to 32 bit conversion

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

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 location. Any idea on how this could be mapped with tablegen correctly? Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. S1-609 One AMD Place Sunnyvale,

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

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

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 >

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

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 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 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'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

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);

Hi everyone, I tried to declare multiple data type [i64, i32, v2i32] for a 64 bit register class GPR. It works OK but I have one problem that is hard to find. When I tried to map a load instruction of a v2i32 type (LOAD v2i32:$dst) to load GPR, it always generate two LOAD i32 instead of one LOAD v2i32. Any folds understand how this works? Xiaochu -------------- next part -------------- An HTML

Micah, Do you mean we should make GPR64 available to register allocator by calling addRegisterClass? addRegisterClass(MVT::i64, &GPR64RegClass) If we add register class GPR64, type legalization will stop expanding i64 operations because i64 is now a legal type. Then we will probably have to write lots of code to custom-lower unsupported 64-bit operations during legalization. Note that

I'm having some troubles implementing vector support to our custom backend It seems that llvm cannot emulate shuffle with extracts, inserts and builds? I've enabled vector registers with addRegisterClass(MVT::v2i32, TCE::V2I32RegsRegisterClass); addRegisterClass(MVT::v2f32, TCE::V2F32RegsRegisterClass); and created patterns for most vector instructions, including insert, extract and

Hi Matt, I did call addRegisterClass in TargetLowering for all the possible types in the register. And for typecasting instructions (i32 to i64), it works. Any other possiblilities? On Thu, Jul 2, 2015 at 6:12 PM Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 07/02/2015 05:56 PM, Xiaochu Liu wrote: > > Hi everyone, > > > > I tried to declare multiple data

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

MIPS Technologies has a new open position in its Sunnyvale, CA headquarters for an LLVM QA Engineer. This engineer will work on testing, QA, building, and benchmarking of the clang/llvm and gcc compilers. They will be responsible for generating test cases to augment already existing test suites, and to test features such as debugging. This engineer will get requirements from the compiler

/// emitProlog/emitEpilog - These methods insert prolog and epilog code into /// the function. The return value is the number of instructions /// added to (negative if removed from) the basic block (entry for prologue). /// virtual void emitPrologue(MachineFunction &MF) const = 0; virtual void emitEpilogue(MachineFunction &MF, MachineBasicBlock

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: