similar to: [LLVMdev] x86 calling conventions refactoring

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 >

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

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

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

Can you file a bug? Thanks. Evan On Jul 22, 2009, at 8:30 AM, robert muth wrote: > 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

On 25/07/12 12:14, Paul Shortis wrote: > Thanks Richard, > > You're correct, they are similar. In the XCoreInstrInfo.td patterns > what I'm struggling with is why this .... > > def BL_lu10 : _FLU10< > (outs), > (ins calltarget:$target, variable_ops), > "bl $target", >

Just filed bugs for this and a new rather severe one involving address arithmetic. Robert On Fri, Jul 24, 2009 at 1:34 AM, Evan Cheng <evan.cheng at apple.com> wrote: > Can you file a bug? Thanks. > Evan > > On Jul 22, 2009, at 8:30 AM, robert muth wrote: > > I have run the torture test again svn head rev 76522 (2009/07/20) there are > now > 2 compilation and 23

Hi Evan, I incoporated the changes you request but to the following i have got a question: > Also, moving the option > there will allow us to change fastcc ABI (callee popping arguments) > only when this option is on. See Chris' email: I am not to sure on that. because that would make modules compiled with the flag on incompatible with ones compiled without the flag off as

On 25/07/12 18:21, Richard Osborne wrote: > On 25 Jul 2012, at 04:49, Paul Shortis wrote: > > >> Hello, >> >> I'm considering creating an LLVM backend for a 16 bit processor and >> modelling it around the (experimental) MSP430 back end. >> >> When reviewing MSP430InstrInfo.td I see >> >> def MSP430Wrapper :

Hello, Arnold. > with the sentence i tried to express the question whether there is a > way to persuade the code generator to use another register to load (or > move) the function pointer to (right before the callee saved register > restore) but thinking a little further that's nonsense. Why don't define some special op for callee address and custom lower it? I really

Seems to be a bit of new warnings recently: llvm/llvm/lib/CodeGen/Spiller.cpp: In function 'void UpdateKills(llvm::MachineInstr&, llvm::BitVector&, std::vector<llvm::MachineOperand*, std::allocator<llvm::MachineOperand*> >&, const llvm::TargetRegisterInfo*)': llvm/llvm/lib/CodeGen/Spiller.cpp:221: warning: unused variable 'TID'

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

Comments: CheckDAGForTailCallsAndFixThem - 1. for (SelectionDAG::allnodes_iterator BE = DAG.allnodes_begin(), + BI = prior(DAG.allnodes_end()); BI != BE; BI--) { Please use pre-decrement instead of post-decrement. 2. The function is slower than it should be. You are scanning all the nodes in the DAG twice. You should just examine DAG.getRoot() to make determine whether it's a

On Oct 5, 2007, at 2:42 AM, Arnold Schwaighofer wrote: > Hi Evan, > I incoporated the changes you request but to the following i have got > a question: > >> Also, moving the option >> there will allow us to change fastcc ABI (callee popping arguments) >> only when this option is on. See Chris' email: > > I am not to sure on that. because that would make

On 24 Sep 2007, at 09:18, Evan Cheng wrote: > +; RUN: llvm-as < %s | llc -march=x86 -mattr=+sse2 -stats -info- > output-file - | grep asm-printer | grep 9 > +; change preceeding line form ... | grep 8 to ..| grep 9 since > +; with new fastcc has std call semantics causing a stack adjustment > +; after the function call > > Not sure if I understand this. Can you illustrate

On Oct 5, 2007, at 10:41 AM, Evan Cheng wrote: > > On Oct 5, 2007, at 2:42 AM, Arnold Schwaighofer wrote: > >> Hi Evan, >> I incoporated the changes you request but to the following i have got >> a question: >> >>> Also, moving the option >>> there will allow us to change fastcc ABI (callee popping arguments) >>> only when this option is

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:

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