Re: support branch predication for vectors ( was: casting "extended vectors"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 7 Jul 2014, Vincenzo Innocente wrote:

On 6 Jul, 2014, at 4:57 PM, Marc Glisse <marc.glisse@xxxxxxxx> wrote:

f you can also try to add something for “movemask” would be also great!

Please file enhancement PRs (after making sure they don't already exist) with as much information as you can. I am unlikely to implement that any time soon, maybe somebody else will be...

For the vector extension, we don't want things that are too specific to a processor. Maybe an operation that takes an integer vector guaranteed to have only 0 and -1 as elements and compacting it to a bitfield would make sense (and the reverse operation), this would be relevant for sparc-vis and for avx512. Movemask seems a bit too weird for direct support.

I submitted PR56829 April last year …
maybe it needs a bit of rewording to attract possible contributors

It sure could do with some more information, like what "movemask" is, links to the documentation of cuda ballot and x86 movemask, etc (if you can find relevant instructions for altivec, neon, vis or some others, it would help convince that this isn't an x86-only feature). The reference to any/all/popcount may not be enough of a motivation, because all 3 are reductions. I would find clz/ctz more convincing.

Not that any of that will make free time magically appear for some contributor :-(

--
Marc Glisse




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux