similar to: [LLVMdev] Can't use SSE4.2 instructions

FYI, The CRC64 intrinsics were renamed to CRC32 since 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.

On Fri, May 3, 2013 at 11:07 AM, Blind Faith <person.of.book at gmail.com>wrote: ... > "You may be passing operands of the wrong type to the intrinsic" -> Well > I don't do anything to the LLVM bit code, I just try to compile my C code, > all code being generated by clang. > Sorry for misunderstanding... I have a simple test here that generates

Hi, When setting -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

Hi, I’m using _mm_storel_epi64/ _mm_loadl_epi64 in my test case as below and generating 32-bit code (using -m32 and -msse4.2). The 64-bit load and 64-bit store operations are replaced with two 32-bit mov instructions, presumably due to the use of uint64_t type. If I use __m128i instead of uint64_t everywhere, then the read and write happen as 64-bit operations using the xmm registers as expected.

Might you instead consider just adding a -disable-mmx option? Preston On Thu, 2008-20-11 at 02:57 -0500, Mon Ping Wang wrote: > Hi, > > When setting -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

On Nov 19, 2008, at 11:57 PMPST, Mon Ping Wang wrote: > Hi, > > When setting -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

Hi Dale, I will not change the default. I would dislike to see any regressions due to this type of change. -- Mon Ping On Nov 20, 2008, at 10:12 AM, Dale Johannesen wrote: > > On Nov 19, 2008, at 11:57 PMPST, Mon Ping Wang wrote: > >> Hi, >> >> When setting -mattr option on X86, I would like to treat MMX >> separately from SSE levels. This would allow a

On Nov 20, 2008, at 8:31 AM, Preston Gurd wrote: > Might you instead consider just adding a -disable-mmx option? I agree, this is a better approach. This distinguishes between capabilities of the chip and the desire to codegen specific vectors one way or another. -Chris > > Preston > > On Thu, 2008-20-11 at 02:57 -0500, Mon Ping Wang wrote: >> Hi, >> >>

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

Hi Nadav, On 2013-08-12 12:59 PM, "Nadav Rotem" <nrotem at apple.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)

We have quite a lot of code in AutoUpgrade.cpp to upgrade X86 intrinsics that have been replaced with native IR over the years. Has enough time and/or versions passed that we can begin phasing out some of this code? As I'm writing these we don't seem to have tests for a lot of the older upgrades. We've done better at this in the last few years. 3.1 added upgrade for:

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:

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

Many of the older autoupgrades have no test cases because I think when we upgraded them we just replace all the code in the tests with native IR. So for some of the code we don't even know if it works. I don't really want to watch the amount of code here continue to grow indefinitely. It's pretty poorly structured and has been up against the MSVC cascaded if/else limit a couple times.

I agree with Paul that we need to formalise the compatibility policy before we start removing support for old intrinsics. Do we want a deprecation warning of some kind for the use of any intrinsic used in auto-upgrade, would that actually be useful or just a nuisance? In the meantime I’m happy to help fix any missing test coverage. > On 20 Sep 2017, at 22:16, Robinson, Paul via llvm-dev

This is a bug in the implementation of WidenVecRes_Binary. On line 1546 it assumes that “Widen” is the last phase of type-legalization and we check if the result is a legal type. But actually we want to continue and promote the elements of the vector. In other cases we may want to widen (to the next power of two) and later split in half because the vector is too big. On Aug 12, 2013, at 10:46

While building llvm & clang & libs by giving some optimization options to the building compiler, the following error happened: I think it is related to the passed -DCLS=64, because in file clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp:6411 an enum member has the same name (CLS), so it does a macro-substitution with the passed value of CLS, ie. with 64, but which of course then breakes

Is there a reason why? IE is it hard to maintain, slow, or are you just worried it will break? or something else? (I'm not opposed in any way, literally just want to understand the motivation) On Wed, Sep 20, 2017 at 12:20 PM, Craig Topper via llvm-dev < llvm-dev at lists.llvm.org> wrote: > We have quite a lot of code in AutoUpgrade.cpp to upgrade X86 intrinsics > that have

Hi, I believe we have a formal policy: we support every bitcode produced since LLVM 3.0: https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility (until we decide to uprev the version we support). Unfortunately, the testing was only added around 3.6 or 3.7? And support is only as good as the testing we have... -- Mehdi 2017-09-21 0:23 GMT-07:00 Simon Pilgrim via llvm-dev <

I think the general backward-compatibility story has been kind of vague for a while. There was some talk about it at the time of the version-numbering change, but I don't remember if it came to any kind of solid conclusion. I think the handling of the old X86 intrinsics would want to follow the general compatibility policy, assuming we can all agree on one. There shouldn't be a special