[PATCH] fix PR46029: reimplement if conversion of loads and stores [3nd submitted version of patch]

Below, please find the 3nd submitted version of this patch, now with some more issues resolved. Regards, Abe From 87af575347e216672e322bbc1b4ae0a5ab93507f Mon Sep 17 00:00:00 2001 From: Abe Date: Mon, 18 May 2015 14:26:29 -0500 Subject: [PATCH] fix PR46029: reimplement if conversion of

revised and updated new-if-converter patch… [PATCH] fix PR46029: reimplement if conversion of loads and stores

e relevant scanned-for text to not be found by DejaGNU so as to prevent the DejaGNU line from being interpreted. The below is also based on a Git checkout that was rebased to the latest upstream check-in from today, so it should merge cleanly with trunk as of today. Regards, Abe

Another benefit of the new if converter: better performance for half hammocks when running the generated code on a modern high-speed CPU with write-back caching, relative to the code produced by the o

_and_ the write path [modulo at most one cache line of both read and write]. I hope the above helps to explain why the new converter is worth merging to trunk, even though for now it still has performance regressions which we expect to fix before the first GCC 6.x is tagged for release. Regards, Abe

Re: revised and updated new-if-converter patch… [PATCH] fix PR46029: reimplement if conversion of loads and stores

lved by adding another layer/level of indirection, _except_ for the problem “I/we/the-program have/has too many layers/levels of indirection”". ;-) Regards, Abe

Re: Another benefit of the new if converter: better performance for half hammocks when running the generated code on a modern high-speed CPU with write-back caching, relative to the code produced by t

_really_ like to get the new converter into trunk ASAP so that there will be many more "eyes" on the code. Also, it is important IMO that this code should not languish for months/years [again], since that is what happened approx. 5 years ago when Sebastian wrote it in the first place. I don`t think a branch is the right place for this code, since the branch would allow the code to die. Regards, Abe

Re: Another benefit of the new if converter: better performance for half hammocks when running the generated code on a modern high-speed CPU with write-back caching, relative to the code produced by t

ult when autovectorization is enabled, then to re-integrate the old converter and implement the switches that will give GCC users access to the modes I described in a recent email from me. You might prefer to delay your code review until I have that all done and a new version of the patch submitted. Regards, Abe

Re: Another benefit of the new if converter: better performance for half hammocks when running the generated code on a modern high-speed CPU with write-back caching, relative to the code produced by t

[Abe wrote:] After I`ve done the SPEC-based analysis, my next planned steps on this work are to disable the code that [in my WIP] currently causes conversion to be enabled by default when autovectorization is enabled, then to re-integrate the old converter and implement the switches that will

Re: Minor typo fixes

Thank you, sir. :-) Regards, Abe On 8/3/15 10:53 PM, Jeff Law wrote: I was starting to look at Abe's changes to the gimple if-converter and realized a handful of the changes were just fixing comments. No reason those shouldn't go in immediately. So I pulled them out and app

[PATCH] fix PR46029: reimplement if conversion of loads and stores [2nd submitted version of patch]

Sebastian Pop Abe Skolnik PR tree-optimization/46029 * tree-data-ref.c (struct data_ref_loc_d): Moved... (get_references_in_stmt): Exported. * tree-data-ref.h (struct data_ref_loc_d): ... here. (get_references_in_stmt): Declared

Re: [PATCH] fix PR46029: reimplement if conversion of loads and stores [2nd submitted version of patch]

On 7/2/15 4:49 AM, Alan Lawrence wrote: Thanks, Abe. You are welcome, sir! :-) As before, I'm still confused here. This still returns false, i.e. bails out of if-conversion, if the statement could trap. Doesn't the scratchpad let us handle that? Or do we just not care because i

Re: [PATCH] fix PR46029: reimplement if conversion of loads and stores [2nd submitted version of patch]

[Abe wrote:] This seems like an opportunity for more optimization in the future [On 7/6/15 10:09 AM, Alan Lawrence wrote:] we get enough benefit from the patch, even without my suggested extra change. Ok, fair enough! Thanks for the clarification. You are welcome, sir. [Alan wrote

RE: fix PR46029: reimplement if conversion of loads and stores

om stale-data problems that could come from corner-case code that takes the address of a thread-local variable and gives that address to another thread [which then proceeds to overwrite the value in the supposedly-thread-local scalar that belongs to a different thread from the one doing the writing] Regards, Abe

Re: [PATCH] fix PR46029: reimplement if conversion of loads and stores [2nd submitted version of patch]

[Alan wrote:] Where can I find info on what the different flag values mean? (I had thought they were booleans [...] [Abe wrote:] Sorry; I don`t know if that is documented anywhere yet. In this case, (-1) simply means "defaulted": on if the vectorizer is on, and off if it

Re: fix PR46029: reimplement if conversion of loads and stores

[Abe wrote:] I believe Sebastian would agree that the new if converter is safer than the old one >> in terms of correctness at the time of running the code being compiled. [...] For now, we have a few performance regressions [snip] [Alan wrote:] TBH my two cents would be

Re: fix PR46029: reimplement if conversion of loads and stores

(if-conversion could directly generate masked load/stores of course and not use a scratch-pad at all in that case). [Abe wrote:] IMO that`s a great idea, but I don`t know how to do it. Hints would be welcome. In particular, how does one >> "generate masked load/stores" at

Re: [PATCH] fix PR46029: reimplement if conversion of loads and stores [2nd submitted version of patch]

[Abe wrote:] Is the following sufficient? From "doc/invoke.texi", I propose to replace: This is enabled by default if vectorization is enabled. ... with: This is enabled by default when vectorization is enabled anddisabled by default when vectorization i

[PATCH] vax: resolve long-standing documentation bugs re floating-point codegen [PR79646]

t it empty.  In at least one case where the translation was empty before, I filled it in. Copyright assignment to the FSF, yadda yadda yadda...  all the usual. Sincerely, Abe From ec5f259d0e7dd7dcd1194f775bf00d3decb786f3 Mon Sep 17 00:00:00 2001 From: Abe Date: Wed, 24 Apr 2024 21:06:50 -0400 Subje

fix PR46029: reimplement if conversion of loads and stores

hread-safe. Passed regression testing and bootstrap on amd64-linux. Is this OK to commit to trunk? Regards, Abe 2015-06-12 Sebastian Pop Abe Skolnik PR tree-optimization/46029 * tree-data-ref.c (struct data_ref_loc_d): Moved... (get_references_in_stmt)