search for: lowerformal_argu

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 Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. S1-609 One AMD Place Sunnyvale, CA. 94085 P: 408-749-3966...

...e 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 LowerCCCArguments was in order to facilitate review (otherwise the diff would contain no useful deltas), but it should go back where it belongs afterwards. LowerX86_64CCCCallTo and LowerX86_64CCCCallTo were consolidated with LowerCCCCa...

...ous 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 > LowerCCCArguments was in order to facilitate review (otherwise the > diff would contain no useful deltas), but it should go back where it > belongs afterwards. > • LowerX86_64CCCCallTo and LowerX86_64CCCCallTo were...

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

...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 manually through va-arg-1.c, it's pretty clear that > there's some disconnect between the register spilling that happens in > LowerFORMAL_ARGUMENTS and what happens in LowerVASTART in > ARMISelLowering.cpp. > > deep > > On Thu, Jun 11, 2009 at 8:45 AM, robert muth<robert at muth.org> wrote: > > I wrote a few scripts to run llvm/arm against the gnu c torture test > suite > > which consists of over 900 s...

I don't have a target in front of me to run these tests at the moment, but walking manually through va-arg-1.c, it's pretty clear that there's some disconnect between the register spilling that happens in LowerFORMAL_ARGUMENTS and what happens in LowerVASTART in ARMISelLowering.cpp. deep On Thu, Jun 11, 2009 at 8:45 AM, robert muth<robert at muth.org> wrote: > I wrote a few scripts to run llvm/arm against the gnu c torture test suite > which consists of  over 900 smallish tests. > > There were qu...

I wrote a few scripts to run llvm/arm against the gnu c torture test suite which consists of over 900 smallish tests. There were quite a few failures with llvm/arm which I hereby want to report (see attached tarball for the actual failing testsc). Most of the failures are related to vararg/stdarg. I think I saw a bug files for this but cannot find it anymore. Is somebody on this? Finally, I

...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 manually through va-arg-1.c, it's pretty clear that > there's some disconnect between the register spilling that happens in > LowerFORMAL_ARGUMENTS and what happens in LowerVASTART in > ARMISelLowering.cpp. > > deep > > On Thu, Jun 11, 2009 at 8:45 AM, robert muth<robert at muth.org> wrote: > > I wrote a few scripts to run llvm/arm against the gnu c torture > test suite > > which consists of over 900...

...<deeppatel1987 at gmail.com>wrote: > >> I don't have a target in front of me to run these tests at the moment, >> but walking manually through va-arg-1.c, it's pretty clear that >> there's some disconnect between the register spilling that happens in >> LowerFORMAL_ARGUMENTS and what happens in LowerVASTART in >> ARMISelLowering.cpp. >> >> deep >> >> On Thu, Jun 11, 2009 at 8:45 AM, robert muth<robert at muth.org> wrote: >> > I wrote a few scripts to run llvm/arm against the gnu c torture test >> suite >> &g...

...;, std::vector<llvm::MachineOperand*, std::allocator<llvm::MachineOperand*> >&)': llvm/llvm/lib/CodeGen/Spiller.cpp:947: warning: unused variable 'TID' llvm/llvm/lib/Target/Mips/MipsISelLowering.cpp: In member function 'llvm::SDValue llvm::MipsTargetLowering::LowerFORMAL_ARGUMENTS(llvm::SDValue, llvm::SelectionDAG&)': llvm/llvm/lib/Target/Mips/MipsISelLowering.cpp:958: warning: 'Opcode' may be used uninitialized in this function

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

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:

...race 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 arguments (copied ISD::MERGE_VALUES from PowerPC implementation, not sure if it is really needed) static SDOperand LowerFORMAL_ARGUMENTS(SDOperand Op, SelectionDAG &DAG){ SmallVector<SDOperand, 8> ArgValues; SDOperand Root = Op.getOperand(0); // Return the new list of results. std::vector<MVT::ValueType> RetVT(Op.Val->value_begin(), Op.Val->value_end()); const...

...LL and it is this one that fails. When I get the arguments to the function call, (SDValue Arg = TheCall->getArg(i);), the returned SDValue is a FrameIndex, and I don't handle the case correctly. The only issue that I have is that none of the other backends have any code in LowerCALL/LowerRET/LowerFORMAL_ARGUMENTS that explicitly handle FrameIndexSDNode's as arguments. This leads me to believe that I shouldn't have to handle this case and there is an error occurring somewhere else and is showing up here. My test case is fairly simple: float func(float *a); void test(float *positions) { float...

On Jan 27, 2009, at 3:54 PM, Villmow, Micah wrote: > Ok, I've had time to track this down a little bit more and I seem to > have found another case where it fails. This is occurring during > Schedulur->EmitSchedule() in SelectionDAGISel.cpp:695. The problem > seems > to be that somehow the CopyToReg part of the switch statement in > ScheduleDAG::EmitNode has a

Ok, I've had time to track this down a little bit more and I seem to have found another case where it fails. This is occurring during Schedulur->EmitSchedule() in SelectionDAGISel.cpp:695. The problem seems to be that somehow the CopyToReg part of the switch statement in ScheduleDAG::EmitNode has a FrameIndex as its second operand. This is especially problematic because the code is either