On Tue, Aug 4, 2015 at 7:05 AM, Jeff Law wrote:
> On 07/17/2015 01:57 PM, Abe wrote:
>>
>> Dear all,
>>
>> Relative to the previous submission of this same patch, the below
>> corrects some minor spacing and/or indentation issues,
>> misc. other formatting fixes, and makes the disabled vectorizati
On 07/17/2015 01:57 PM, Abe wrote:
Dear all,
Relative to the previous submission of this same patch, the below
corrects some minor spacing and/or indentation issues,
misc. other formatting fixes, and makes the disabled vectorization tests
be disabled via "xfail" rather than by adding spaces to
d
[Alan wrote:]
> Would having a testsuite predicate for the target supporting gathered loads
> let you run this test on those architectures? I'd expect one to be useful
> in a few other places too, in time if it doesn't exist already...
Thanks, but I don`t think that would fully fix all the regres
Abe wrote:
diff --git a/gcc/testsuite/gcc.dg/vect/if-cvt-stores-vect-ifcvt-18.c
b/gcc/testsuite/gcc.dg/vect/if-cvt-stores-vect-ifcvt-18.c
index 71f2db3..2b159d7 100644
--- a/gcc/testsuite/gcc.dg/vect/if-cvt-stores-vect-ifcvt-18.c
+++ b/gcc/testsuite/gcc.dg/vect/if-cvt-stores-vect-ifcvt-18.c
@@
From 89e115118dcc49d6839db2e9d7ae6c330789c235 Mon Sep 17 00:00:00 2001
Subject: [PATCH] fix PR46029: reimplement if conversion of loads and stores
In the current implementation of if conversion, loads and stores are
if-converted in a thread-unsafe way:
* loads were always executed, even when they shoul
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
[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 is disabled.
[Al
Abe wrote:
[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 is
(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 the GIMPLE level?
[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 that a performanc
[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 is off.
(0) mea
On Tue, Jul 7, 2015 at 11:23 PM, Abe wrote:
>> (if-conversion could directly generate masked load/stores
>> of course and not use a scratch-pad at all in that case).
>
>
> 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 mas
Abe wrote:
I`m uncertain to what that is intended to refer, but 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.
>
even if they take us a step backwards from a performance standpoint.
(if-conversion could directly generate masked load/stores
of course and not use a scratch-pad at all in that case).
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 the GIMPLE level?
But are we cor
On 06/25/2015 03:43 AM, Richard Biener wrote:
Yes, and if you just look at scalar code then with the rewrite we can
enable store if-conversion unconditionally.
_But_
when the new scheme triggers vectorization cannot succeed on the
result as we get
if (cond)
*p = val;
if-converted to
[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:]
Abe wrote:
On 7/2/15 4:49 AM, Alan Lawrence wrote:
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 it won't be vectorizable anyway???
This seems
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 it won't be v
Thanks, Abe. A couple comments below...
@@ -883,7 +733,7 @@ if_convertible_gimple_assign_stmt_p (gimple stmt,
if (flag_tree_loop_if_convert_stores)
{
- if (ifcvt_could_trap_p (stmt, refs))
+ if (ifcvt_could_trap_p (stmt))
{
if (ifcvt_can_use_mask_load_store
New relative to previous version of same patch:
* addressed comments/suggestions from Alan and Richard.
* disabled the test cases that are currently not if-converted correctly,
pending improvements to the new if-converter
Passed regression testing and bootstrap on amd64-linux.
2015-06-12 S
Abe Skolnik wrote:
In tree-if-conv.c:[…]> if it doesn't trap, but has_non_addressable_refs, can't
we use
ifcvt_can_use_mask_load_store there too?
if an access could trap, but is addressable,> can't we use the scratchpad
technique
to get round the trapping problem?
That`s how we deal with loa
On 06/26/2015 08:57 AM, Richard Biener wrote:
Another possibility is to not share them and make sure to insert clobbers for
them when they become dead so later stack slot sharing can merge them again.
We've certainly had cases in the past where re-using a stack slot for an
object that has gone
On June 26, 2015 2:21:22 PM GMT+02:00, Alan Lawrence
wrote:
>Sebastian Pop wrote:
>> On Thu, Jun 25, 2015 at 4:43 AM, Richard Biener
>> wrote:
>>> when the new scheme triggers vectorization cannot succeed on the
>>> result as we get
>>>
>>> if (cond)
>>> *p = val;
>>>
>>> if-converted to
>
Sebastian Pop wrote:
On Thu, Jun 25, 2015 at 4:43 AM, Richard Biener
wrote:
when the new scheme triggers vectorization cannot succeed on the
result as we get
if (cond)
*p = val;
if-converted to
tem = cond ? p : &scratch;
*tem = val;
That's correct.
and
if (cond)
val =
On Thu, Jun 25, 2015 at 4:43 AM, Richard Biener
wrote:
> when the new scheme triggers vectorization cannot succeed on the
> result as we get
>
> if (cond)
> *p = val;
>
> if-converted to
>
> tem = cond ? p : &scratch;
> *tem = val;
That's correct.
>
> and
>
>if (cond)
> val =
On Wed, Jun 24, 2015 at 7:10 PM, Jeff Law wrote:
> On 06/22/2015 10:27 AM, Alan Lawrence wrote:
>
>>
>> My main thought concerns the direction we are travelling here. A major
>> reason why we do if-conversion is to enable vectorization. Is this is
>> targetted at gathering/scattering loads? Follow
On 06/22/2015 10:27 AM, Alan Lawrence wrote:
My main thought concerns the direction we are travelling here. A major
reason why we do if-conversion is to enable vectorization. Is this is
targetted at gathering/scattering loads? Following vectorization,
different elements of the vector being load
On 06/24/2015 10:50 AM, Ramana Radhakrishnan wrote:
On 12/06/15 21:50, Abe Skolnik wrote:
Hi everybody!
In the current implementation of if conversion, loads and stores are
if-converted in a thread-unsafe way:
* loads were always executed, even when they should have not been.
Some so
On 12/06/15 21:50, Abe Skolnik wrote:
Hi everybody!
In the current implementation of if conversion, loads and stores are
if-converted in a thread-unsafe way:
* loads were always executed, even when they should have not been.
Some source code could be rendered invalid due to null point
Abe Skolnik wrote:
Hi everybody!
In the current implementation of if conversion, loads and stores are
if-converted in a thread-unsafe way:
* loads were always executed, even when they should have not been.
Some source code could be rendered invalid due to null pointers
that were OK in
Hi everybody!
In the current implementation of if conversion, loads and stores are
if-converted in a thread-unsafe way:
* loads were always executed, even when they should have not been.
Some source code could be rendered invalid due to null pointers
that were OK in the original program
31 matches
Mail list logo
