search for: sse42

...nce there is no such thing. See below for details. Chad On May 26, 2011, at 4:13 PM, Chad Rosier wrote: > Author: mcrosier > Date: Thu May 26 18:13:19 2011 > New Revision: 132163 > > URL: http://llvm.org/viewvc/llvm-project?rev=132163&view=rev > Log: > Renamed llvm.x86.sse42.crc32 intrinsics; crc64 doesn't exist. > crc32.[8|16|32] have been renamed to .crc32.32.[8|16|32] and > crc64.[8|16|32] have been renamed to .crc32.64.[8|64]. > > > > Added: > llvm/trunk/test/CodeGen/X86/sse42_64.ll > Modified: > llvm/trunk/include/llvm/Int...

...ng -mattr option on X86, I would like to treat MMX separately from SSE levels. This would allow a client who sets the attributes directly to set the SSE level independent of MMX, e.g., llc -march=x86 -mattr=sse41, one would get sse4.1 with mmx disabled while llc -march=x86 -mattr=mmx -mattr=sse42 will get mmx and sse42. If anyone objects to this change, please let me know. Thanks, -- Mon Ping

...tion on X86, I would like to treat MMX > separately from SSE levels. This would allow a client who sets the > attributes directly to set the SSE level independent of MMX, e.g., llc > -march=x86 -mattr=sse41, one would get sse4.1 with mmx disabled while > llc -march=x86 -mattr=mmx -mattr=sse42 will get mmx and sse42. If > anyone objects to this change, please let me know. > > Thanks, > -- Mon Ping > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu...

...tion on X86, I would like to treat MMX > separately from SSE levels. This would allow a client who sets the > attributes directly to set the SSE level independent of MMX, e.g., llc > -march=x86 -mattr=sse41, one would get sse4.1 with mmx disabled while > llc -march=x86 -mattr=mmx -mattr=sse42 will get mmx and sse42. If > anyone objects to this change, please let me know. I don't object, but please don't change the defaults. You're likely to find places the SSE code assumes MMX exists...

...o treat MMX >> separately from SSE levels. This would allow a client who sets the >> attributes directly to set the SSE level independent of MMX, e.g., >> llc >> -march=x86 -mattr=sse41, one would get sse4.1 with mmx disabled while >> llc -march=x86 -mattr=mmx -mattr=sse42 will get mmx and sse42. If >> anyone objects to this change, please let me know. > > I don't object, but please don't change the defaults. > You're likely to find places the SSE code assumes MMX exists... > > _______________________________________________ > LLV...

...o treat MMX >> separately from SSE levels. This would allow a client who sets the >> attributes directly to set the SSE level independent of MMX, e.g., >> llc >> -march=x86 -mattr=sse41, one would get sse4.1 with mmx disabled while >> llc -march=x86 -mattr=mmx -mattr=sse42 will get mmx and sse42. If >> anyone objects to this change, please let me know. >> >> Thanks, >> -- Mon Ping >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu &gt...

Hi, I'm trying to use the SSE4.2's instruction _mm_crc32_u64 and also added -msse4.2 flag in the makefile, but yet I get this error when I try to compile my code with clang/llvm. LLVM ERROR: Cannot select: intrinsic %llvm.x86.sse42.crc32.64.64 I also tried to pass -march=native, but still no luck. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130503/943f2a47/attachment.html>

Hi, I am trying to understand how vector type legalization works. In particular, I'm looking at i8 vector types on x86 (with sse42 features) v3i8 gets widened to v4i8 and then operations get unrolled (scalarized) because v4i8 is not a legal type whereas v4i8 gets promoted to v4i32. Why doesn't v3i8 (or even v4i8) get widened to v16i8? Alternatively, v3i8 could be widened to v4i8 then promoted to v4i32 but this doesn't...

...e.com> wrote: >Hi Paul, > >You can read about it here: >http://blog.llvm.org/2011/12/llvm-31-vector-changes.html > >> Hi, >> >> I am trying to understand how vector type legalization works. In >>particular, I'm looking at i8 vector types on x86 (with sse42 features) >> >> v3i8 gets widened to v4i8 and then operations get unrolled (scalarized) >>because v4i8 is not a legal type whereas v4i8 gets > >This does not sound right. v3i8 -> v4i8 is okay. But the next step >should be v4i8 -> v4i32. The operation nay be scal...

...53.9 no SSE enabled 55.2 SSE1 disabled 53.9 SSE1 enabled 55.3 SSE2 disabled 51.9 SSE2 enabled 53.1 SSE3 disabled 51.8 SSE3 enabled 53.2 SSSE3 disabled 45.7 SSSE3 enabled 51.4 SSE41 disabled 46.1 SSE41 enabled 51.6 SSE42 disabled 46.1 SSE42 enabled 51.6 Conclusions: 1) flac is always faster when precompute_partition_info_sums_32bit_asm_ia32_() is disabled. 2) Some C code benefits noticeably from SSSE3 instructions; at least when compiled with GCC 4.8.1.

This patch moves all info->ia32.fxsr = info->ia32.sse = info->ia32.sse2 = info->ia32.sse3 = info->ia32.ssse3 = info->ia32.sse41 = info->ia32.sse42 = false; expressions into a static function disable_sse(FLAC__CPUInfo *info). -------------- next part -------------- A non-text attachment was scrubbed... Name: simplify_cpu_c.zip Type: application/zip Size: 1163 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments...

Hi Paul, You can read about it here: http://blog.llvm.org/2011/12/llvm-31-vector-changes.html > Hi, > > I am trying to understand how vector type legalization works. In particular, I'm looking at i8 vector types on x86 (with sse42 features) > > v3i8 gets widened to v4i8 and then operations get unrolled (scalarized) because v4i8 is not a legal type whereas v4i8 gets This does not sound right. v3i8 -> v4i8 is okay. But the next step should be v4i8 -> v4i32. The operation nay be scalarized in the vector legaliz...

...tests for this x86.sse41.ptest.* had its signature chagned and we upgrade from the old signature. We don't have tests for the old signature. x86.xop.vfrcz.ss/sd had an argument dropped that we upgrade for. We don't have any tests for the old signature. 3.3 had no upgrades 3.4 removed: x86.sse42.crc32.64.8 we do have tests that use it For the complete list of intrinsic upgrade support, there's an annotated list in ShouldUpgradeX86Intrinsic in AutoUpgrade.cpp ~Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm...

...gt; >> You can read about it here: >> http://blog.llvm.org/2011/12/llvm-31-vector-changes.html >> >>> Hi, >>> >>> I am trying to understand how vector type legalization works. In >>> particular, I'm looking at i8 vector types on x86 (with sse42 features) >>> >>> v3i8 gets widened to v4i8 and then operations get unrolled (scalarized) >>> because v4i8 is not a legal type whereas v4i8 gets >> >> This does not sound right. v3i8 -> v4i8 is okay. But the next step >> should be v4i8 -> v4i32...

...ts signature chagned and we upgrade from the old > signature. We don't have tests for the old signature. > x86.xop.vfrcz.ss/sd had an argument dropped that we upgrade for. We don't > have any tests for the old signature. > > 3.3 had no upgrades > > 3.4 removed: > x86.sse42.crc32.64.8 we do have tests that use it > > For the complete list of intrinsic upgrade support, there's an annotated > list in ShouldUpgradeX86Intrinsic in AutoUpgrade.cpp > > ~Craig > > _______________________________________________ > LLVM Developers mailing list >...

...alloc(i64) #1 declare void @bar1(i8*) #2 declare void @bar2(i8*) #2 declare i32 @bar3(i8*) #2 attributes #0 = { nounwind ssp uwtable "target-cpu"="core2" "target-features"="-sse4a,-avx2,-xop,-fma4,-bmi2,-3dnow,-3dnowa,-pclmul,+sse,-avx,-sse41,+ssse3,+mmx,-rtm,-sse42,-lzcnt,-f16c,-popcnt,-bmi,-aes,-fma,-rdrand,+sse2,+sse3" } attributes #1 = { nounwind "target-cpu"="core2" "target-features"="-sse4a,-avx2,-xop,-fma4,-bmi2,-3dnow,-3dnowa,-pclmul,+sse,-avx,-sse41,+ssse3,+mmx,-rtm,-sse42,-lzcnt,-f16c,-popcnt,-bmi,-aes,-fma,-rd...

...ade from the old >> signature. We don't have tests for the old signature. >> x86.xop.vfrcz.ss/sd had an argument dropped that we upgrade for. We don't >> have any tests for the old signature. >> >> 3.3 had no upgrades >> >> 3.4 removed: >> x86.sse42.crc32.64.8 we do have tests that use it >> >> For the complete list of intrinsic upgrade support, there's an annotated >> list in ShouldUpgradeX86Intrinsic in AutoUpgrade.cpp >> >> ~Craig >> >> _______________________________________________ >> LL...

...g...done. done. (gdb) run < /etc/iptables.post Starting program: /usr/bin/iptables-xml < /etc/iptables.post <iptables-rules version="1.0"> <!-- # Managed by puppet --> <table name="filter" > Program received signal SIGSEGV, Segmentation fault. __strcmp_sse42 () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:165 165 movdqu (%rsi), %xmm2 (gdb) bt #0 __strcmp_sse42 () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:165 #1 0x00000000004041f8 in needChain (chain=0x0) at iptables-xml.c:276 #2 iptables_xml_main (argc=<optimized out>, argv=<...

...had its signature chagned and we upgrade from the old signature. We don't have tests for the old signature. > x86.xop.vfrcz.ss/sd had an argument dropped that we upgrade for. We don't have any tests for the old signature. > > 3.3 had no upgrades > > 3.4 removed: > x86.sse42.crc32.64.8 we do have tests that use it > > For the complete list of intrinsic upgrade support, there's an annotated list in ShouldUpgradeX86Intrinsic in AutoUpgrade.cpp > > ~Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists....

...tests for this x86.sse41.ptest.* had its signature chagned and we upgrade from the old signature. We don't have tests for the old signature. x86.xop.vfrcz.ss/sd had an argument dropped that we upgrade for. We don't have any tests for the old signature. 3.3 had no upgrades 3.4 removed: x86.sse42.crc32.64.8 we do have tests that use it For the complete list of intrinsic upgrade support, there's an annotated list in ShouldUpgradeX86Intrinsic in AutoUpgrade.cpp ~Craig _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-...