craig.topper added inline comments.
================ Comment at: lib/Headers/mmintrin.h:1292 /// -/// This intrinsic corresponds to the <c> VXORPS / XORPS </c> instruction. +/// This intrinsic corresponds to the <c> XOR </c> instruction. /// ---------------- kromanova wrote: > craig.topper wrote: > > PXOR? > For which platform/compiler? > > I checked, for x86_64 Linux XORPS(no avx)/VXORPS (with -mavx) is generated. > For PS4 we generate XORL. > > I guess, we need to write something more generic, implying that an > appropriate platform-specific XOR instruction is generated. Ideally to interoperate with other mmx intrinsics it should have been a PXOR into an mmx register. But apparently our mmx support is so limited that we aren't capable of that and instead create it in another domain and move it over. I guess just indicate it as a utility function with no specific instruction. ================ Comment at: lib/Headers/mmintrin.h:1384 /// -/// This intrinsic corresponds to the <c> VPSHUFD / PSHUFD </c> instruction. +/// This intrinsic corresponds to the <c> PSHUFD </c> instruction. /// ---------------- kromanova wrote: > craig.topper wrote: > > This is overly specific there is no guarantee we'd use those instructions. > > If it was a constant we'd probably just use a load. > That's right. I think we should use the following wording to match other > _mm_set* intrinsics documentation in this file. > > /// This intrinsic is a utility function and does not correspond to a specific > /// instruction. > Agreed. https://reviews.llvm.org/D41517 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
