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

Thu Sep 21 22:47:11 PDT 2017

FWIW, I think if we're going to do this we should try to find a useful
non-trivial bump. Are there other things we could clean up if we bumped to,
for example 4.0?

On Thu, Sep 21, 2017 at 10:06 PM Mehdi AMINI via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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 <
> llvm-dev at lists.llvm.org>:
>
>> 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 <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> 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 case for those IMO.  So, starting a new
>> non-X86-specific thread about backward compatibility would be appropriate.
>> --paulr
>>
>> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org
>> <llvm-dev-bounces at lists.llvm.org>] *On Behalf Of *Craig Topper via
>> llvm-dev
>> *Sent:* Wednesday, September 20, 2017 1:01 PM
>> *To:* Daniel Berlin
>> *Cc:* llvm-dev
>> *Subject:* Re: [llvm-dev] RFC: [X86] Can we begin removing AutoUpgrade
>> support for x86 instrinsics added in early 3.X versions
>>
>> 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
>>
>>
> _______________________________________________
> 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/20170922/c1328639/attachment.html>