Michael Hope michael.hope@linaro.org writes:
On Fri, May 20, 2011 at 2:07 AM, Richard Sandiford richard.sandiford@linaro.org wrote:
I've added some ideas to the NEON blueprint. There are now really 6 separate tasks, broken down into subitems, so it looks like we really could have 6 separate blueprints, as you mentioned on the wiki page. I wasn't sure how to create those blueprints correctly though. Please let me know if they don't look sensible!
Let's collect things first. Providing the topics have sufficient meat in them then I'll split them into blueprints later.
Hmm. The whole 'Do topic A; Commit upstream; Commit in Linaro' work item repetition is unfortunate. It's correct but it hides the topics in the noise.
Yeah. I suppose one advantage of splitting the blueprint up might be that each "real" task becomes more obvious.
How about also 'Ensure vectorised code doesn't regress over non-vectorised code'? The goal would be for 90 % of benchmarks to not regress and 99 % to regress no more than 2 %. At the moment good 'ol CoreMark is worse with -O3 -omfpu=neon...
Well, I suppose if we're setting figures like that, then it's really "Limit regressions in vectorised code over non-vectorised code". :-) But maybe it'd be better to keep figures out of it. 99% is awkward because I don't think we even have 100 benchmarks yet. And what about benchmarks like DENbench that run the same code more than once, but with a different data set? Does each data set count as a separate benchmark?
Maybe 'Deal with regressions in vectorised code over non-vectorised code.', if that isn't too wishy-washy? With the usual "commit upstream" and "commit to Linaro 4.6" too, of course.
FWIW, all the examples I've seen so far are due to the over-promotion of vector operations (e.g. doing things on ints when shorts would do).
Richard