search for: 048266

...39;ve come to the conclusion that the real flaw is LLVM > not exposing enough information to the target-dependent > backend code for it to do the right thing. We also had this problem. You might find this patch useful as a starting point: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/048266.html /Patrik Hägglund -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Tim Northover Sent: den 30 mars 2012 21:58 To: Bob Wilson; Anton Korobeynikov Cc: James Molloy; cfe-commits; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [cf...

...ion that the real flaw is LLVM > > not exposing enough information to the target-dependent > > backend code for it to do the right thing. > > We also had this problem. You might find this patch useful as a starting > point: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/048266.html Thanks. I'd considered using MachineFunction fiddling purely from a LowerFormalArguments perspective (I hadnn't noticed the subtlety that LowerCall needs this info to be passed in). Doesn't this mean you have to replicate all the machinations of SelectionDAGBuilder to work out...

Hi, (Forward from cfe-commits, where some backend stuff has come up). This is an issue I've been thinking about quite a bit recently, and I agree that the biggest problem is the one below: > * The big thing still missing here is that there is no logic to check how many VFP registers have already been used for other arguments. When deciding whether to pass an argument as a homogeneous