Re: GIMPLE-level if-converter with scratchpads --- Results from SPEC2006 FP analysis done at Richard`s request {late July / early August} --- results from running all the SPEC2006 CPU FP tests again a

ut to that point: quoting Richard`s check-in message: "PR tree-optimization/66823 * tree-if-conv.c (memrefs_read_or_written_unconditionally): Fix inverted predicate."] All the compilations were done with "-Ofast". The results, all integers, are the number of loop

Re: Results from SPEC2006 FP analysis done at Richard`s request {late July / early August}

[Richard wrote:] Ah, so for a meaningful comparison -march=native should be used. Otherwise we don't get much store if-conversion anyway. Understood. I`ll adjust configuration files accordingly and redo the analyses. Please look for an updated report from me later this week. Regards, Abe

Re: Results from SPEC2006 FP analysis done at Richard`s request {late July / early August}

generic AMD64/x86_64 does _not_ have the gathering stuff and the very latest from Intel _does_. Sorry, but I don`t know about the masked form[s]. If that`s important to know, then please tell me and I will investigate. Regards, Abe

Results from SPEC2006 FP analysis done at Richard`s request {late July / early August}

base: 7421 new: 7401 I have a spreadsheet [and a PDF generated therefrom] that shows the above in a more visual format. Please feel free to ask for the PDF as an email attachment. Regards, Abe

Re: making the new if-converter not mangle IR that is already vectorizer-friendly

[Abe wrote:] TTBOMK, that "expense" is temporary, pending fixes/improvement to the new converter. IOW, I don`t think any of the relevant regressions are as a result of "essential complexity". [Richard wrote:] I don't see how you can fix this without scatter suppor

Re: making the new if-converter not mangle IR that is already vectorizer-friendly

h / without the new > if-converter (and if you like also without -ftree-loop-if-convert-stores). > You can use -fopt-info-vec and grep for the number of 'loop vectorized' cases. Please consider it added to my "TO DO" list. I`ll report back when I have results. Regards, Abe

Re: making the new if-converter not mangle IR that is already vectorizer-friendly

[Abe wrote:] Ideally, I/we fix the above problem -- and the rest of the regressions in the new if converter -- [Alan wrote:] OK, what are these regressions? Each of these files` test cases currently fails to be autovectorized: gcc/testsuite/gcc.dg/vect/pr61194.c gcc/testsuite/gcc.dg

Re: making the new if-converter not mangle IR that is already vectorizer-friendly

one before autovectorization and therefor at the GIMPLE level. Corrections are welcome. [Abe wrote:] The preceding makes me wonder: has anybody considered adding an optimization profile for GCC, […] that optimizes for the amount of energy consumed? >> I don`t remember reading about anyt

Re: making the new if-converter not mangle IR that is already vectorizer-friendly

[Abe wrote:] After finishing fixing the known regressions, I intend/plan to reg-test for AArch64; after that, I think I`m going to need some community help to reg-test for other ISAs. [Alan wrote:] OK, I'm confused. When you write "making the new if-converter not mangle IR".

Re: making the new if-converter not mangle IR that is already vectorizer-friendly [from Abe Fri. 2015-July-10 ~4:25pm US Central time, same date ~9:25pm UTC: responses to Richard, comments on: vectori

for which the autovectorizer is successful in generating vector code. Those are probably the main reasons why the new converter is worth hacking on to get it into shape, performance-regression-wise. Plus, this is work that my employer [Samsung] is willing and able to fund at this time [by paying my salary while I work on it ;-)]. Regards, Abe

Re: making the new if-converter not mangle IR that is already vectorizer-friendly

[Abe wrote:] [snip] Even without cmove to/from main memory, two cmoves back-to-back with opposite conditions could still be used, e.g. [not for a real-world ISA]: load X[x] -> reg1 load Y[y] -> reg2 cmove c ? reg1 -> reg3 cmove (!c) ? reg2 -> reg3 Or even better if

Re: making the new if-converter not mangle IR that is already vectorizer-friendly

control flow, and so is vectorizable. [snip] > (This is all without your scratchpad patch, of course.) I think the preceding is quite correct. Sebastian and I have discussed [at some length, on my part ;-)] what to do about the flags. We definitely want them to change. We might wind up with a different number of flags, i.e. not just rename one or both of the two we currently have. Does anybody know of any large codebase that depends heavily on the current flags? AFAIK these have been infrequently-if-ever used so far in production code. Regards, Abe

Re: making the new if-converter not mangle IR that is already vectorizer-friendly

On 7/2/15 4:30 AM, Alan Lawrence wrote: Hi, pleased to meet you :) Likewise. :-) [Abe wrote:] * Always safe for stores, sometimes a little risky for loads: speculative loads might cause multithreaded programs with insufficient locking to fail due to writes by another thread

making the new if-converter not mangle IR that is already vectorizer-friendly

Dear all, [Please feel free to skip to the second instance of "end of introductions" and read the introduction sections later or never.] Hi! My name is Abe. Although I`m from New York City, I`ve been living in Texas for about 5 years now, due to having been "sucked in&quo