similar to: [LLVMdev] LowerArguments vs LowerFORMAL_ARGUMENTS

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

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

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

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

Hi all, The attachment supersedes the previous patch. It incorporates some feedback from Anton and takes the next step of merging the largely duplicated calling convention logic in X86ISelLowering. LowerCCCArguments, LowerX86_64CCCArguments and LowerFastCCArguments are merged and inlined directly into LowerFORMAL_ARGUMENTS. I moved LowerFORMAL_ARGUMENTS to the location where

On 2008-01-01, at 20:05, Gordon Henriksen wrote: > The attachment supersedes the previous patch. It incorporates some > feedback from Anton and takes the next step of merging the largely > duplicated calling convention logic in X86ISelLowering. > > • LowerCCCArguments, LowerX86_64CCCArguments and > LowerFastCCArguments are merged and inlined directly into >

Hi, In SelectionDAGISel::SelectAllBasicBlocks if (TM.Options.EnableFastISel) FastIS = TLI->createFastISel(*FuncInfo, LibInfo); followed by if (!FastIS) { LowerArguments(Fn); } else { The above implies that implementing FastIS is optional. In contrast to that, testing whether FastIS is actually been used is done by testing if TM.Options.EnableFastISel is set. For example

On Sep 16, 2009, at 5:58 AM, Kenneth Uildriks wrote: >> I recently made a major reorganization of the calling-convention >> lowering code which cleared away one of the major obstacles to >> doing this within codegen. >> >> Dan > > So what was the obstacle, and how was it cleared? The biggest obstacle is that there used to be two different methods for lowering

Currently, Alpha, PowerPC and X86 implement LowerFORMAL_ARGUMENTS. PowerPC and X86 lower ISD::CALL in LowerOperation. Alpha implements custom select. What is the preferred way to implement this? Thanks, Rafael

I'm hitting a problem in SelectionDAGBuild::visitRet(), mainly: MVT VT = ValueVTs[j]; // FIXME: C calling convention requires the return type to be promoted to // at least 32-bit. But this is not necessary for non-C calling // conventions. if (VT.isInteger()) { MVT MinVT = TLI.getRegisterType(MVT::i32); if (VT.bitsLT(MinVT)) VT = MinVT;

Hi everyone, It seems variable arguments is not support by mips backend in llvm-2.6. int func(int i, ...) { return 0; } llvm-gcc func.c -emit-llvm -c -O3 -o func.bc llc func.bc -relocation-model=static -march=mips -O0 -o func.s Command llc fails: llc:SelectionDAGBuilder.cpp:6440:void llvm::SelectionDAGISel::LowerArguments( llvm::BasicBlock):Assertion 'Invals.size() ==

> I recently made a major reorganization of the calling-convention > lowering code which cleared away one of the major obstacles to > doing this within codegen. > > Dan So what was the obstacle, and how was it cleared? And how do you see the large struct return working in codegen? Anything you care to tell me would be welcome. I will be starting on this today or tomorrow.

I have run the torture test again svn head rev 76522 (2009/07/20) there are now 2 compilation and 23 runtime failure. A tarball with reproducers is attached. Most problems are still vargs related. Robert On Fri, Jun 12, 2009 at 11:09 AM, Sandeep Patel <deeppatel1987 at gmail.com>wrote: > I don't have a target in front of me to run these tests at the moment, > but walking