similar to: [LLVMdev] ABI: how to let the backend know that an aggregate should be allocated on stack

On Tue, Oct 23, 2012 at 11:22 AM, manman ren <mren at apple.com> wrote: > > Hi All, > > I am trying to handle the Homogeneous Aggregate for ARM-VFP according to the > spec: > > C.1.vfp If the argument is a VFP CPRC and there are sufficient consecutive > VFP registers of the appropriate type unallocated then the argument is > allocated to the lowest-numbered

Byval does not work for me, it will try to split the struct to fit into available core registers and the rest on stack. Sent from my iPhone On Oct 23, 2012, at 5:01 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > In llvm-gcc, this decision was handled near llvm-arm.cpp:2737 in llvm_arm_aggregate_partially_passed_in_regs(). Basically, available registers would be counted up and if

In llvm-gcc, this decision was handled near llvm-arm.cpp:2737 in llvm_arm_aggregate_partially_passed_in_regs(). Basically, available registers would be counted up and if the HA didn't fit, it went byval instead. I agree that we should unify this sort of logic in one place. I'm not sure that onstack is the best interim step toward that. Does byval work here? Alex On Oct 23, 2012, at

At the time, the ARM target didn't actually handle byval. Now it does. You should be able to get the old struct passing capability if you don't apply an attribute at all. Alex On Oct 23, 2012, at 10:00 PM, Manman Ren wrote: > > Byval does not work for me, it will try to split the struct to fit into available core registers and the rest on stack. > > Sent from my iPhone

On Oct 20, 2012, at 12:58 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Rafael, > > On 19/10/12 18:27, Rafael Espíndola wrote: >>> Don't get me wrong, I don't have any good ideas about how to do this, I'm >>> just hoping someone does. End result might allow something like: >>> >>> declare void @foo(double inreg <eax,edx>

> Don't get me wrong, I don't have any good ideas about how to do this, I'm > just hoping someone does. End result might allow something like: > > declare void @foo(double inreg <eax,edx> %x) Not sure I would go all the way to specifying registers in the IL (although I liked it at some point). What I like most right now is something along the lines of

>>> Not sure I would go all the way to specifying registers in the IL >>> (although I liked it at some point). What I like most right now is >>> something along the lines of >>> http://llvm.org/pr12193. That makes it explicit if something is on the >>> stack or in registers and that information is correct for both the >>> caller and callee.

Hi Rafael, On 19/10/12 18:27, Rafael Espíndola wrote: >> Don't get me wrong, I don't have any good ideas about how to do this, I'm >> just hoping someone does. End result might allow something like: >> >> declare void @foo(double inreg <eax,edx> %x) > > Not sure I would go all the way to specifying registers in the IL > (although I liked it at

Hello, This is the second version of this patch series. I only implement the VPF context switch support for arm32 and add dummy function to avoid compilation on arm64. I have switched the order of the patch because the old second one can be applied alone and the patch are cleaner :). For all the changes see each patch. Cheers, Julien Grall (2): xen/arm: don''t enable VFP on XEN

On 25 March 2016 at 04:11, Hal Finkel <hfinkel at anl.gov> wrote: > As I understand it, the fundamental property being addresses here is: Are the semantics of scalar FP math the same as vector FP math? TTI seems like a good place to expose that information. If the semantics are indeed different, then the vectorizer would require fast-math flags in order to vectorize FP operations

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

Folks, I'm now looking at https://llvm.org/bugs/show_bug.cgi?id=16274, which seems to have some support in the vectorizer, but not as we need for this particular case. I may have missed something obvious, please let me know if there is a better way. As you already know, ARM has two FP instruction sets: VFP and NEON. VFP applies to single FP registers while NEON is a full SIMD. The problem is

Debian file server hangs or freezes every time a visual foxpro (vfp) built exe file located or stored in it is executed from within a local area network consisting of windows (XP) and linux (debian) boxes. If only windows boxes are utilized to access the vfp program, server never fails; but when a linux box joins in and runs the vfp through wine, server hangs or freezes within 1 to 2 hours.

On May 12, 2011, at 12:30 AM, Sandeep Patel wrote: > On Wed, May 11, 2011 at 11:42 PM, Stuart Hastings <stuart at apple.com> wrote: >> >> On May 9, 2011, at 1:41 PM, Renato Golin wrote: >> >> [snip] >> >>> One example is the struct byval. The ARM back-end still doesn't >>> support struct byval (maybe now it does, I was away for a

On 12 May 2011 15:43, Stuart Hastings <stuart at apple.com> wrote: > I'm not familiar with AAPCS-VFP, but I'd assume that any byval struct should be passed by value, as if byval didn't exist. Not if the argument(s) fits into the specified registers. There's where the ABI comes in. In a nutshell, the AAPCS-VFP extends the AAPCS to include cases where the arguments are

Hi Sandeep, >> The ARM backend now supports struct byval for APCS. Extending it to support AAPCS shouldn't be too difficult. Alas, I won't have time to revisit this in the near future. > > It's slightly unclear to me what byval means for an ABI that passes > some structs in registers, such as AAPCS-VFP. I think in that case the front-end is supposed to extract the

The linux builds are not using SSE right now, but the vector data is 16-byte aligned on all platforms. So if you port this SSE code to another platform (Linux, Altivec, NEON), you could contribute it back to Bullet? The most interesting SSE part is the innerloop of the constraint solver: http://tinyurl.com/ydoapct Some developers replaced some linear algebra functions (in Bullet/LinearMath) with

Hi, > James, is that a correct assessment? Yes, it is also my belief that the only way ARMv7 NEON differs from IEEE754 is lack of denormal support. James > On 11 Feb 2016, at 10:53, Renato Golin <renato.golin at linaro.org> wrote: > > Hal, > > I had a read on the ARM ARM about VFP and SIMD FP semantics and my > analysis is that NEON's only problem is the

On 18 December 2013 12:31, Tim Northover <t.p.northover at gmail.com> wrote: > That's what I thought! But we do seem to generate vfma on Cortex-A9. > Wonder if that's a bug, or Cortex-A9 is "VFPv3, but chuck in vfma > too"? > Hi Tim, I believe that's the NEON VMLA, not the VFP one. There was a discussion in the past about not using NEON and VFP

Hi Tim, > > cortex-a15 vfpv4 : vmla instruction emitted (which is a NEON instruction) > > I get a VFP vmla here rather than a NEON one (clang -target > armv7-linux-gnueabihf -mcpu=cortex-a15): "vmla.f32 s0, s1, s2". Are > you seeing something different? > As per Renato comment above, vmla instruction is NEON instruction while vmfa is VFP instruction. Correct