Michael Hope <michael.h...@linaro.org> writes: > On Fri, May 20, 2011 at 2:07 AM, Richard Sandiford > <richard.sandif...@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 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
