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

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
<mailto: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
<mailto: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 <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170921/c1c236a0/attachment.html>

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

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>

(resend with llvm-dev back in the cc list)

We have policy for what we support; we don't have a policy for when do we
change what we support.  The policy was clear in the early 3.x era, but
circumstances changed as we got to 4.0, and the only point of agreement was to
stay with "back to 3.0."
LLVM 3.0 was released 6 years ago; it might be time to drop some of the older
versions?
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Mehdi
AMINI via llvm-dev
Sent: Thursday, September 21, 2017 10:06 PM
To: Simon Pilgrim
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] RFC: [X86] Can we begin removing AutoUpgrade support for
x86 instrinsics added in early 3.X versions

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<mailto: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<mailto: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] 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<mailto: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<mailto: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<mailto: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/7ae76593/attachment.html>