search for: formal_arguments

...; [#uses=1] > ret i64 %tmp3 > --------------------------------------- > > When the DAG is constructed it will contain a load from formal_args. It shouldn't contain a load: the "a" argument (which represents the address by-val arg) will be one of the results of the formal_arguments node. Ah, you probably mean the explicit load will turn into a load SDNode, which is right :) > It looks like a lot of work to modify the DAG so that instead it uses > a copy. Even if we decide to do this, we would need to pass the size > of the structure to the DAG, which currently is...

On 27/07/07, Evan Cheng <evan.cheng at apple.com> wrote: > Code generator shouldn't introspect the LLVM type at all, except to > get the size of the type. Anything needed should be encoded by the > front-end. In the short term, please focus on getting parity with > what we already have. This means x86-64 will be wrong, but it > already is. As a second step we can then

Hello, I want to find information/documentation on how reorganize stack frame (add other information, etc.) & how add new calling convention into ARM backend? I think it is needed to modify lowering of CALL, RET & FORMAL_ARGUMENT instruction, and also to modify emitPrologue & emitEpilogue functions. What are the others things to modify in order to realize my

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 formal arguments when it crashes so I'm not sure if I may be breaking something in there. Here is my code in the formalizing argu...

...de generators to lower functions arguments that have the "byval" attribute, they would have to access the original argument Type. For example, on linux x86_64 {i64, i64} should be passed on registers and {i64, i64, i64} goes on the stack. The problem is that when looking at (for example) FORMAL_ARGUMENTS, the only thing that is present is the type of the pointer itself (i64 for example). I can see three options to solve the problem: 1) Make FORMAL_ARGUMENTS have one SrcValueSDNode per argument in addition to the flags and make CALL use SrcValueSDNode for the arguments. The calling convention func...

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 allocation. So if...

...ring for tail calls. Before this patch all outgoing arguments were move to the stack slot where they would go on a normal function call and from there moved back to the tail call stack slot to prevent overwriting of values. After this patch only arguments that source from callers arguments (formal_arguments) are lowered this way. I moved some code that would otherwise be duplicated to a new function 'GetMemCpyWithFlags'. Okay to commit? regards arnold -------------- next part -------------- A non-text attachment was scrubbed... Name: tailcall-improvement.patch Type: application/octet-st...

...split the register up. I'd suggest going up the stack to figure out who called LegalizeOp instead of ExpandOp. > Here is my code in the formalizing arguments (copied ISD::MERGE_VALUES > from PowerPC implementation, not sure if it is really needed) MergeValues is required because the FORMAL_ARGUMENTs node returns one value for each argument input to the function, and also a chain value. These have to match up correctly. -Chris

...plement any call sequences, stack frames etc. I get the following assertion failure: llc: LegalizeDAG.cpp:834: llvm::SDOperand <unnamed>::SelectionDAGLegalize::LegalizeOp(llvm::SDOperand): Assertion `Tmp3.Val->getNumValues() == Result.Val->getNumValues() && "Lowering call/formal_arguments produced unexpected # results!"' failed. This is what my LowerCALL looks like: SDOperand MCTargetLowering::LowerCALL(SDOperand Op, SelectionDAG &DAG) { SDOperand Chain = Op.getOperand(0); bool isVarArg = cast<ConstantSDNode>(Op.getOperand(2))->getValue() !=...

On Sep 28, 2007, at 11:36 AM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com> wrote: > I moved my code to 2.1 but still the same. > If I make ADD i16 legal, then it goes through, but it has problem > expanding it to i8. > Should I go ahead and customize it and do the same for all > instructions? > Or there is a more general thing that I

...ajor change, affecting all targets, so I'm looking for feedback on the approach. The goal of the patch is to eliminate a bunch of awkward code, eliminate some unnecessary differences between targets, and to facilitate future refactoring and feature work. This patch gets rid of ISD::CALL, ISD::FORMAL_ARGUMENTS, ISD::RET, and ISD::ISD::ARG_FLAGS, as well as the old LowerArguments and LowerCallTo hooks. To replace them, it adds three new TargetLowering hooks: LowerCall, LowerFormalArguments, and LowerReturn. These hooks provide targets with the same information as the special nodes, except in an immediatel...

...argets, so I'm looking for feedback on the approach. > > The goal of the patch is to eliminate a bunch of awkward code, > eliminate some unnecessary differences between targets, and to > facilitate future refactoring and feature work. > > This patch gets rid of ISD::CALL, ISD::FORMAL_ARGUMENTS, ISD::RET, and > ISD::ISD::ARG_FLAGS, as well as the old LowerArguments and LowerCallTo > hooks. To replace them, it adds three new TargetLowering hooks: > LowerCall, LowerFormalArguments, and LowerReturn. These hooks provide > targets with the same information as the special nodes, exc...

...unctions arguments that have > the "byval" attribute, they would have to access the original argument > Type. For example, on linux x86_64 {i64, i64} should be passed on > registers and {i64, i64, i64} goes on the stack. > > The problem is that when looking at (for example) FORMAL_ARGUMENTS, > the only thing that is present is the type of the pointer itself (i64 > for example). > > I can see three options to solve the problem: > > 1) Make FORMAL_ARGUMENTS have one SrcValueSDNode per argument in > addition to the flags and make CALL use SrcValueSDNode for the >...

...s etc. > > I get the following assertion failure: > > llc: LegalizeDAG.cpp:834: llvm::SDOperand > <unnamed>::SelectionDAGLegalize::LegalizeOp(llvm::SDOperand): > Assertion `Tmp3.Val->getNumValues() == Result.Val->getNumValues() > && "Lowering call/formal_arguments produced unexpected # results!"' > failed. > > This is what my LowerCALL looks like: > > SDOperand MCTargetLowering::LowerCALL(SDOperand Op, SelectionDAG > &DAG) { > SDOperand Chain = Op.getOperand(0); > bool isVarArg = cast<ConstantSDNo...

I moved my code to 2.1 but still the same. If I make ADD i16 legal, then it goes through, but it has problem expanding it to i8. Should I go ahead and customize it and do the same for all instructions? Or there is a more general thing that I can do? A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent:

...e following assertion failure: > > > > llc: LegalizeDAG.cpp:834: llvm::SDOperand > > <unnamed>::SelectionDAGLegalize::LegalizeOp(llvm::SDOperand): > > Assertion `Tmp3.Val->getNumValues() == Result.Val->getNumValues() > > && "Lowering call/formal_arguments produced unexpected # results!"' > > failed. > > > > This is what my LowerCALL looks like: > > > > SDOperand MCTargetLowering::LowerCALL(SDOperand Op, SelectionDAG > > &DAG) { > > SDOperand Chain = Op.getOperand(0); > > bo...

Hello everybody, hi Evan, this patch changes the lowering of arguments for tail call optimized calls. Before arguments that could be overwritten by each other were explicitly lowered to a stack slot, not giving the register allocator a chance to optimize. Now a sequence of copyto/copyfrom virtual registers ensures that arguments are loaded in (virtual) registers before they are lowered to the

...ets, so I'm looking for feedback on the approach. > > The goal of the patch is to eliminate a bunch of awkward code, > eliminate some unnecessary differences between targets, and to > facilitate future refactoring and feature work. Nice! > This patch gets rid of ISD::CALL, ISD::FORMAL_ARGUMENTS, ISD::RET, and > ISD::ISD::ARG_FLAGS, as well as the old LowerArguments and LowerCallTo > hooks. To replace them, it adds three new TargetLowering hooks: > LowerCall, LowerFormalArguments, and LowerReturn. These hooks provide > targets with the same information as the special nodes, exc...

...lue): Assertion `(Tmp3.getNode()->getNumValues() == Result.getNode()->getNumValues() || (Tmp3.getNode()->getNumValues() == Result.getNode()->getNumValues() + 1 && Tmp3.getNode()->getValueType(Tmp3.getNode()->getNumValues() - 1) == MVT::Flag)) && "Lowering call/formal_arguments produced unexpected # results!"' failed. Stack dump: 0. Program arguments: llc 1. Running pass 'ARM Instruction Selection' on function '@foo' Aborted 3. Could not match memory address errors http://labb.zafena.se/shark-testing/llvmARMCodeGenFailures200904/matchmemoryaddr...

...split the register up. I'd suggest going up the stack to figure out who called LegalizeOp instead of ExpandOp. > Here is my code in the formalizing arguments (copied ISD::MERGE_VALUES > from PowerPC implementation, not sure if it is really needed) MergeValues is required because the FORMAL_ARGUMENTs node returns one value for each argument input to the function, and also a chain value. These have to match up correctly. -Chris _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman...