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 ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
