llvm dev - Sep 2017 - RFC: [X86] Can we begin removing AutoUpgrade support for x86 instrinsics added in early 3.X versions

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170920/5b5df0bf/attachment.html>

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>

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 think they allow about 128.
Of course this is fixable by better structuring, but we'd probably want to
fix the lack of tests to be more confident about not breaking it.

The ridiculous number of string compares in the code might be slow, but I'm
not sure. I've never tried to profile it. We don't divide up the string
compares based on first letters or anything so I think we run through a lot
of memcmps.

Unfortunately, the bulk of the upgrade code was added in the 3.7, 3.9, 4.0
timeframe so the big reduction in code probably requires several more
years. But I wanted to start a conversation about what our compability
story looks like going forward.

~Craig

On Wed, Sep 20, 2017 at 12:31 PM, Daniel Berlin <dberlin at dberlin.org>
wrote:
> 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/49336392/attachment.html>