Displaying 4 results from an estimated 4 matches for "xmmn".
Did you mean:
xmm0
2009 Dec 04
0
[LLVMdev] Win64 Calling Convention problem
...ged by type legalizer. I have no
> idea why MS decided not to
> pass then in registers... This is silly...
Hmm, maybe I can explain this: The Microsoft docs state that for
unprototyped functions floating-point values need to be passed as
double precision in both the floating-point registers (XMMn) and the
integer registers (RCX, etc.). That obviously doesn't work for SSE
vectors because they don't fit into the integer registers. So, there's
only pass-by-reference of the first four vectors, which they might
have generalized to all functions (even with complete signatures) for
con...
2009 Dec 04
2
[LLVMdev] Win64 Calling Convention problem
Hello, Stephan
> I didn't know about exceptions like _Complex that you mentioned. The
> only way to support them is to place the burden of correct parameter
> passing on the front-end, I understand that now.
Right. Especially when ABI dictates quite "weird" rules (read e.g.
x86-64 ABI or ARM EABI).
We do support one "exception" though for win64 - __m128 vectors.
2018 Feb 27
2
Missed optimization - spill/load generated instead of reg-to-reg move (and two other questions)
...rsion of the code: https://godbolt.org/g/ec5cP7 <https://godbolt.org/g/ec5cP7>
My main question concerns assembly lines 37/38 and 59/60, where xmm0 is spilled
to the stack, only to be immediately reloaded into xmm1. Google tells me that
there is a register-to-register mov instruction for the xmmn registers, so I
found it odd that LLVM missed what looks like an easy optimization. tstellar on
#llvm pointed me towards using -debug-only=regalloc with llc to see what LLVM is
thinking (regalloc log here, since I'm not sure what's considered "too large"
for mailing lists: [0]), a...
2018 Feb 28
0
Missed optimization - spill/load generated instead of reg-to-reg move (and two other questions)
...sed version of the code: https://godbolt.org/g/ec5cP7
>
> My main question concerns assembly lines 37/38 and 59/60, where xmm0
> is spilled
> to the stack, only to be immediately reloaded into xmm1. Google tells
> me that
> there is a register-to-register mov instruction for the xmmn
> registers, so I
> found it odd that LLVM missed what looks like an easy optimization.
> tstellar on
> #llvm pointed me towards using -debug-only=regalloc with llc to see
> what LLVM is
> thinking (regalloc log here, since I'm not sure what's considered "too
>...