Comments on: Vectiquette I think what petecubano was saying is that only use them when you really do mean to touch memory; as if you don't (especially on PPU) the compiler may not optimize away to a register-based operation if the value is actually in a register already (due to previous optimizations or whatever).I had not seen your other articles there, very nice :) I think what petecubano was saying is that only use them when you really do mean to touch memory; as if you don’t (especially on PPU) the compiler may not optimize away to a register-based operation if the value is actually in a register already (due to previous optimizations or whatever).I had not seen your other articles there, very nice :)

]]>
By: Jaymin Kessler/2011/01/31/vectiquette/#comment-488 Jaymin Kessler Wed, 02 Feb 2011 02:24:42 +0000 examples of times you definitely want to use memory intrinsics instead of doing loads in C.

]]>
By: Jaymin Kessler/2011/01/31/vectiquette/#comment-487 Jaymin Kessler Wed, 02 Feb 2011 02:20:38 +0000 Holy glaring omission, batman! Stephen is right. I pretty much assumed that people would know the SIMD registers need to be 4-wide to be able to properly return in registers (in many cases), but it is something that needs to be mentioned. The not returning by reference thing is mainly for safety and convenience. In simple cases, I'm sure it works but why take chances? Point 2 says that a function parameter type has to fit in a register for you to pass it by value. Point 3 was meant to extend point 2 to return values. Sorry, I should have said "if the return type fits in a register." Also, like I said, I just think return by reference is too inconvenient as it keeps you from writing nice chained expressions. However, if return by ref is your only option than what can you do? Holy glaring omission, batman! Stephen is right. I pretty much assumed that people would know the SIMD registers need to be 4-wide to be able to properly return in registers (in many cases), but it is something that needs to be mentioned. The not returning by reference thing is mainly for safety and convenience. In simple cases, I’m sure it works but why take chances? Point 2 says that a function parameter type has to fit in a register for you to pass it by value. Point 3 was meant to extend point 2 to return values. Sorry, I should have said “if the return type fits in a register.” Also, like I said, I just think return by reference is too inconvenient as it keeps you from writing nice chained expressions. However, if return by ref is your only option than what can you do?

]]>
By: Stephen./2011/01/31/vectiquette/#comment-485 Stephen. Tue, 01 Feb 2011 18:32:56 +0000 Great article! I've been looking at very similar things recently. One more that i'd like to add to the list is "Be careful when using intrinsics that access memory". They don't yet appear to be optimized away so the code below generates far more instructions for the 2 cases, even though they are effectively identical.vector float something();vector float foo(){ vector float f = something(); return (vector float)si_lqd(si_from_ptr(&f), 0);}vector float bar(){ vector float f = something(); return *(vector float*)&f;}Actually, on a similar vein, don't access memory in inline assembly either. Do all the accesses before the assembly then pass the data in. That allows GCC to propagate variables and constants which is very likely to happen after inlining occurs. Like you said, this isn't a hard "dont do it", but just think about it first, and look at the disassembly :) Great article! I’ve been looking at very similar things recently. One more that i’d like to add to the list is “Be careful when using intrinsics that access memory”. They don’t yet appear to be optimized away so the code below generates far more instructions for the 2 cases, even though they are effectively identical.vector float something();vector float foo(){ vector float f = something(); return (vector float)si_lqd(si_from_ptr(&f), 0);}vector float bar(){ vector float f = something(); return *(vector float*)&f;}Actually, on a similar vein, don’t access memory in inline assembly either. Do all the accesses before the assembly then pass the data in. That allows GCC to propagate variables and constants which is very likely to happen after inlining occurs. Like you said, this isn’t a hard “dont do it”, but just think about it first, and look at the disassembly :)

]]>
By: Colin Riley/2011/01/31/vectiquette/#comment-483 Colin Riley Mon, 31 Jan 2011 12:15:07 +0000