On Fri, Jul 31, 2015 at 7:43 PM, Abe wrote:
> [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 ho
[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 support in the CPU.
Well, for som
On Wed, Jul 29, 2015 at 6:15 PM, Abe wrote:
> [Richard wrote:]
>>
>> Yes, the GIMPLE if-converter should strictly be a vectorization enabler.
>> If the "new" if-converter produces code that the vectorizer does not
>> handle (on the target targeted) then it has done a bad job.
>
>
> Understood [or
[Richard wrote:]
Yes, the GIMPLE if-converter should strictly be a vectorization enabler.
If the "new" if-converter produces code that the vectorizer does not
handle (on the target targeted) then it has done a bad job.
Understood [or at least I _think_ I did ;-)] and agreed.
OTOH, there _are_
On Tue, Jul 21, 2015 at 10:19 PM, Abe wrote:
> First: my apologies for the delay in this reply.
Likewise ;)
>
> [Richard wrote:]
>>
>> Well, but we do have a pretty strong if-converter on RTL
>
>> which has access to target specific information.
>
> Yes, I have had a quick look at it. It looks
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
> Behalf Of Abe
> Sent: Wednesday, July 22, 2015 4:20 AM
>
> [Abe wrote:]
> >> The preceding makes me wonder: has anybody considered adding an
> optimization
> >> profile for GCC, […] that optimizes for the amount of energy
> consumed
[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/ve
First: my apologies for the delay in this reply.
[Richard wrote:]
Well, but we do have a pretty strong if-converter on RTL
> which has access to target specific information.
Yes, I have had a quick look at it. It looks quite thorough.
I think I see that you [Richard] are implying that the
Abe wrote:
Ideally, I/we fix the above problem -- and the rest of the regressions in the
new if converter --
Ok, what are these regressions? You say you've tested on x86_64 and only
ifcvt-18.c fails (hence your xfail), so how does one find them?
In particular, I remember that "result = co
[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"...
> does "the n
Abe wrote:
of course this says nothing about whether there is *some* other ISA that gets
regressed!
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.
OK, I'm confused.
On Fri, Jul 10, 2015 at 11:39 PM, Abe wrote:
>> The GIMPLE level if-conversion code was purely
>> written to make loops suitable for vectorization.
>
>
> I`m not surprised to read that.
>
>
>> It wasn't meant to provide if-conversion of
>> scalar code in the end (even though it does).
>
>
> Seren
The GIMPLE level if-conversion code was purely
written to make loops suitable for vectorization.
I`m not surprised to read that.
It wasn't meant to provide if-conversion of
scalar code in the end (even though it does).
Serendipity sure is nice. ;-)
We've discussed enabling the versioni
On Fri, Jul 3, 2015 at 11:37 AM, Alan Lawrence wrote:
> Abe wrote:
>
>> In other words, the problem about which I was concerned is not going to be
>> triggered by e.g. "if (c) x = ..."
>> which lacks an attached "else x = ..." in a multithreaded program without
>> enough locking just because 'x'
On Tue, Jul 7, 2015 at 10:55 PM, Abe wrote:
> [Alan wrote:]
>
>> My understanding is that any decision as to whether one or both of y or z
>> is evaluated (when 'evaluation' involves doing any work,
>> e.g. a load), has already been encoded into the gimple/tree IR. Thus, if
>> we are to only evalu
[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 the ISA can su
Abe wrote:
[snip]
Predication of instructions can help to remove the burden of the conditional
branch, but is not available on all relevant architectures.
In some architectures that are typically implemented in modern high-speed
processors -- i.e. with high core frequency, caches, speculative e
[Alan wrote:]
My understanding is that any decision as to whether one or both of y or z is
evaluated (when 'evaluation' involves doing any work,
e.g. a load), has already been encoded into the gimple/tree IR. Thus, if we are
to only evaluate one of 'y' or 'z' in your example,
the IR will (prio
Abe wrote:
In other words, the problem about which I was concerned is not going to be triggered by
e.g. "if (c) x = ..."
which lacks an attached "else x = ..." in a multithreaded program without
enough locking just because 'x' is global/static.
The only remaining case to consider is if some
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
being
Abe wrote:
Hi, pleased to meet you :)
As some of you already know, at SARC we are working on a new "if converter" to
help convert
simple "if"-based blocks of code that appear inside loops into an
autovectorizer-friendly form
that closely resembles the C ternary operator ["c ? x : y"]. G
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" to Texas by Texas A
22 matches
Mail list logo
