On 8/5/17, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Sat, Aug 5, 2017 at 12:21 PM, Ivan Kalvachev <ikalvac...@gmail.com>
> wrote:
>> On 8/5/17, Rostislav Pehlivanov <atomnu...@gmail.com> wrote:
>>> On 4 August 2017 at 23:58, Ivan Kalvachev <ikalvac...@gmail.com> wrote:
>>>> >> I had it mixed before, but I changed it to be consistent.
>>>> >> Some new avx instruction are not overloaded or
>>>> >> available without their "v-" prefix.
>>>> >> e.g. x86util uses vpbroadcastw in SPLATW.
>>>> >
>>>> > Every instruction that has both a legacy encoding and a VEX-encoding
>>>> > will be automatically converted to VEX in AVX functions when written
>>>> > without the v-prefix. There is no legacy encoding for newer
>>>> > instructions so there's no reason for x86inc to overload those.
>>>> That's great, but it doesn't address the original problem.
>>>> Do you insist on removing the "v-" prefix from AVX only instructions?
>>> I insist.
>> If you insist, then you should have a good technical reason for it.
>> Something that is not based on looks, cosmetics or "it has always been
>> like this".
>> For example, slow compilation because of unnecessary macro expansion is
>> a technical reason to keep the "v-" prefix.
> Consistency with the typical style of our codebase is also a reason.

No, it is not. This fall in category of doing things wrong,
because we have always done them wrong.
Also you brought up the matter of compilation speed,
now you don't care about it? ;)

Don't worry, I will do the requested change,
only because in future it might help with
avx1 & ymm integer test.

Please answer my other question(s).
ffmpeg-devel mailing list

Reply via email to