[llvm-dev] RFC: [X86] Can we begin removing AutoUpgrade support for x86 instrinsics added in early 3.X versions
Daniel Berlin via llvm-dev
llvm-dev at lists.llvm.org
Wed Sep 20 12:31:32 PDT 2017
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 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:
> x86.sse2.pcmpeq.* - we have almost no test cases for this
> x86.sse2.pcmpgt.* - we no test cases for this
> x86.avx2.pcmpeq.* - we have no test cases
> x86.avx2.pcmpgt.* - we have no test cases for this
> x86.avx.vpermil.* - we do test this
>
> 3.2 added upgrade for:
> x86.avx.movnt.* - we have tests for this
> x86.xop.vpcom* - we have 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
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170920/4c1eae23/attachment.html>
More information about the llvm-dev
mailing list