sdesmalen added a comment.

In D131547#3728867 <https://reviews.llvm.org/D131547#3728867>, @dmgreen wrote:

> In D131547#3728842 <https://reviews.llvm.org/D131547#3728842>, @sdesmalen 
> wrote:
>
>> In D131547#3723083 <https://reviews.llvm.org/D131547#3723083>, @dmgreen 
>> wrote:
>>
>>> I think we usually try to do the same, if the intrinsics have been in 
>>> released compilers. There is an example in 
>>> https://reviews.llvm.org/D98487#change-tOTTgECYYAO5, hopefully these would 
>>> be equally simple.
>>
>> We don't really have the intention in keeping compatibility for intrinsics 
>> like these, since the vector.extract/insert intrinsics are the proper way to 
>> insert/extract vectors and they have been around for quite some time now. 
>> Also these intrinsics are quite specific to the initial SVE ACLE 
>> implementation when we first upstreamed it, so it's not very likely that 
>> anyone else is using them.
>
> I'm not sure what you mean by "keeping compatibility", they just need to be 
> replaced in the autoupdate code. If there was a release of llvm which emitted 
> the intrinsics, then the default assumption is that someone might have 
> bitcode that uses them.

What I meant with 'keeping compatibility' is exactly what you described; 
bitcode/IR that uses the old intrinsics remaining to work with newer versions 
of LLVM.

My point was that these intrinsics have not been in LLVM for that long and have 
a very limited scope, so are unlikely to have accrued much legacy. I don't 
really expect a practical use-case where people have legacy SVE ACLE bitcode 
that they need to compile with a newer version of LLVM. So unless someone 
explicitly requests the compatibility, we'd rather remove them in favour of 
adding code that will never be used.

Is there a formal requirement that LLVM must remain backward compatible with 
older LLVM IR (beyond the target-independent parts)?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131547/new/

https://reviews.llvm.org/D131547

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to