Hi,
I continued looking into EEMBC benchmarks: - telecom fft is not vectorized because unknown number of iterations. It has both non-constant step and its loop bound may overflow. I think, the solution here could be loop versioning, but since versioning increases code size, this kind of optimization can be less beneficial. - telecom viterbi (vectorization potential gain is 4x) requires conditional store sinking and load hoisting to enable if-conversion. I worked on implementation of store sinking this week.
Ira
Hi Ira,
On Thu, 2010-12-16 at 15:29 +0200, Ira Rosen wrote:
- telecom viterbi (vectorization potential gain is 4x) requires
conditional store sinking and load hoisting to enable if-conversion. I worked on implementation of store sinking this week.
Is this the only feature that viterbi needs for vectorization ?
From some research that Tejas did earlier this year, I thought that
viterbi was among the hardest to vectorize because in addition to what you mention we need to support vld/st2 or (ofcourse vzip and vld1 if we don't support vld2) instructions and the other vbif / vbsl instructions to support vectorization for viterbi.
I see that we support v<cond> in the backend now but we don't support the vector bitfield instructions like vbit / vbif and vbsl which can be used for vector select other than through intrinsics.
I could be of-course missing something here ....
cheers Ramana
Ira
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Hi Ramana,
On 16 December 2010 20:11, Ramana Radhakrishnan ramana.radhakrishnan@arm.com wrote:
Hi Ira,
On Thu, 2010-12-16 at 15:29 +0200, Ira Rosen wrote:
- telecom viterbi (vectorization potential gain is 4x) requires
conditional store sinking and load hoisting to enable if-conversion. I worked on implementation of store sinking this week.
Is this the only feature that viterbi needs for vectorization ?
From some research that Tejas did earlier this year, I thought that
viterbi was among the hardest to vectorize because in addition to what you mention we need to support vld/st2 or (ofcourse vzip and vld1 if we don't support vld2) instructions and the other vbif / vbsl instructions to support vectorization for viterbi.
Right, we need vld2 and vst2 for Viterbi, and we are working on their implementation (see this thread for the latest discussion http://lists.linaro.org/pipermail/linaro-toolchain/2010-December/000540.html).
I see that we support v<cond> in the backend now but we don't support the vector bitfield instructions like vbit / vbif and vbsl which can be used for vector select other than through intrinsics.
I haven't checked this. But in any case vector select is very important and it's a good idea to support it anyway.
Ira
I could be of-course missing something here ....
cheers Ramana
Ira
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Hi Ira,
Sorry about the delayed response. Filters broke somehow and I saw this mail only today.
On Sat, 2010-12-18 at 16:14 +0000, Ira Rosen wrote:
Right, we need vld2 and vst2 for Viterbi, and we are working on their implementation (see this thread for the latest discussion http://lists.linaro.org/pipermail/linaro-toolchain/2010-December/000540.html).
Ok - that sounds interesting. I wasn't sure if load / store sinking alone would end up giving us the 4x gain that we could get from vectorising viterbi.
I see that we support v<cond> in the backend now but we don't
support
the vector bitfield instructions like vbit / vbif and vbsl which can
be
used for vector select other than through intrinsics.
I haven't checked this. But in any case vector select is very important and it's a good idea to support it anyway.
I went back and looked into it again and it appears as though the support is in there already thanks to Julian. So it needs the vld2 support and the hoisting / sinking bits you mention.
cheers Ramana
Ira
I could be of-course missing something here ....
cheers Ramana
Ira
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
linaro-toolchain@lists.linaro.org
-
Ira Rosen -
Ramana Radhakrishnan