Hi Richard,
I send you updated version of patch which contains fixes you mentioned
and additional early exit in
register_edge_assert_for() for gcond with vector comparison - it tries
to produce assert for
if (vect != {0,0,0,0}) but can't create such constant. This is not
essential since this is
On Wed, Nov 11, 2015 at 2:13 PM, Yuri Rumyantsev wrote:
> Richard,
>
> What we should do to cope with this problem (structure size increasing)?
> Should we return to vector comparison version?
Ok, given this constraint I think the cleanest approach is to allow
integer(!) vector equality(!) compar
Richard,
What we should do to cope with this problem (structure size increasing)?
Should we return to vector comparison version?
Thanks.
Yuri.
2015-11-11 12:18 GMT+03:00 Richard Biener :
> On Tue, Nov 10, 2015 at 3:56 PM, Ilya Enkovich wrote:
>> 2015-11-10 17:46 GMT+03:00 Richard Biener :
>>> O
On Tue, Nov 10, 2015 at 3:56 PM, Ilya Enkovich wrote:
> 2015-11-10 17:46 GMT+03:00 Richard Biener :
>> On Tue, Nov 10, 2015 at 1:48 PM, Ilya Enkovich
>> wrote:
>>> 2015-11-10 15:33 GMT+03:00 Richard Biener :
On Fri, Nov 6, 2015 at 2:28 PM, Yuri Rumyantsev wrote:
> Richard,
>
>
On Nov 10, 2015, at 6:56 AM, Ilya Enkovich wrote:
> 2015-11-10 17:46 GMT+03:00 Richard Biener :
>> On Tue, Nov 10, 2015 at 1:48 PM, Ilya Enkovich
>> wrote:
>>> 2015-11-10 15:33 GMT+03:00 Richard Biener :
On Fri, Nov 6, 2015 at 2:28 PM, Yuri Rumyantsev wrote:
> Richard,
>
> I t
2015-11-10 17:46 GMT+03:00 Richard Biener :
> On Tue, Nov 10, 2015 at 1:48 PM, Ilya Enkovich wrote:
>> 2015-11-10 15:33 GMT+03:00 Richard Biener :
>>> On Fri, Nov 6, 2015 at 2:28 PM, Yuri Rumyantsev wrote:
Richard,
I tried it but 256-bit precision integer type is not yet supported.
On Tue, Nov 10, 2015 at 1:48 PM, Ilya Enkovich wrote:
> 2015-11-10 15:33 GMT+03:00 Richard Biener :
>> On Fri, Nov 6, 2015 at 2:28 PM, Yuri Rumyantsev wrote:
>>> Richard,
>>>
>>> I tried it but 256-bit precision integer type is not yet supported.
>>
>> What's the symptom? The compare cannot be e
2015-11-10 15:33 GMT+03:00 Richard Biener :
> On Fri, Nov 6, 2015 at 2:28 PM, Yuri Rumyantsev wrote:
>> Richard,
>>
>> I tried it but 256-bit precision integer type is not yet supported.
>
> What's the symptom? The compare cannot be expanded? Just add a pattern then.
> After all we have modes up
On Fri, Nov 6, 2015 at 2:28 PM, Yuri Rumyantsev wrote:
> Richard,
>
> I tried it but 256-bit precision integer type is not yet supported.
What's the symptom? The compare cannot be expanded? Just add a pattern then.
After all we have modes up to XImode.
Richard.
> Yuri.
>
>
> 2015-11-06 15:56
Richard,
I tried it but 256-bit precision integer type is not yet supported.
Yuri.
2015-11-06 15:56 GMT+03:00 Richard Biener :
> On Mon, Nov 2, 2015 at 4:24 PM, Yuri Rumyantsev wrote:
>> Hi Richard,
>>
>> I've come back to this optimization and try to implement your proposal
>> for comparison:
On Mon, Nov 2, 2015 at 4:24 PM, Yuri Rumyantsev wrote:
> Hi Richard,
>
> I've come back to this optimization and try to implement your proposal
> for comparison:
>> Btw, you didn't try the simpler alternative of
>>
>> tree type = type_for_mode (int_mode_for_mode (TYPE_MODE (vectype)));
>> build2 (
Hi All!
I prepared another patch which performs insertion additional check on
zero mask for masked stores if only parameter
PARAM_ZERO_TEST_FOR_MASK_STORE has non-zero value. My attempt to use
approach proposed by Richard with simpler alternative for comparison -
use scalar type for 256-bit was no
Hi Richard,
I've come back to this optimization and try to implement your proposal
for comparison:
> Btw, you didn't try the simpler alternative of
>
> tree type = type_for_mode (int_mode_for_mode (TYPE_MODE (vectype)));
> build2 (EQ_EXPR, boolean_type_node,
> build1 (VIEW_CONVERT, type, op0), bu
On Thu, Aug 13, 2015 at 1:32 PM, Yuri Rumyantsev wrote:
> Hi Richard,
>
> Did you have a chance to look at updated patch?
Having a quick look now. Btw, you didn't try the simpler alternative of
tree type = type_for_mode (int_mode_for_mode (TYPE_MODE (vectype)));
build2 (EQ_EXPR, boolean_type_
Hi Richard,
Did you have a chance to look at updated patch?
Thanks.
Yuri.
2015-08-06 14:07 GMT+03:00 Yuri Rumyantsev :
> HI All,
>
> Here is updated patch which implements Richard proposal to use vector
> comparison with boolean result instead of target hook. Support for it
> was added to ix86_e
HI All,
Here is updated patch which implements Richard proposal to use vector
comparison with boolean result instead of target hook. Support for it
was added to ix86_expand_branch.
Any comments will be appreciated.
Bootstrap and regression testing did not show any new failures.
ChangeLog:
2015-
On Fri, Jul 24, 2015 at 9:11 PM, Jeff Law wrote:
> On 07/24/2015 03:16 AM, Richard Biener wrote:
>>>
>>> Is there any rationale given anywhere for the transformation into
>>> conditional expressions? ie, is there any reason why we can't have a
>>> GIMPLE_COND where the expression is a vector cond
On 07/24/2015 03:16 AM, Richard Biener wrote:
Is there any rationale given anywhere for the transformation into
conditional expressions? ie, is there any reason why we can't have a
GIMPLE_COND where the expression is a vector condition?
No rationale for equality compare which would have the se
On Thu, Jul 23, 2015 at 10:03 PM, Jeff Law wrote:
> On 07/20/2015 09:05 AM, Yuri Rumyantsev wrote:
>>
>> Hi Jeff!
>>
>> Thanks for your details comments.
>>
>> You asked:
>> How are conditionals on vectors usually handled? You should try to
>> mimick that and report, with detail, why that's not w
Jeff,
The goal of this transformation is to not execute masked store if
possible,i.e. when is is equal to zero-vector. and conditional
expression is not suitable for it - we must generate semi-hammock with
conditional branch.
Yuri.
2015-07-23 23:03 GMT+03:00 Jeff Law :
> On 07/20/2015 09:05 AM,
On 07/20/2015 09:05 AM, Yuri Rumyantsev wrote:
Hi Jeff!
Thanks for your details comments.
You asked:
How are conditionals on vectors usually handled? You should try to
mimick that and report, with detail, why that's not working.
In current implementation of vectorization pass all comparisons
On Mon, Jul 20, 2015 at 5:05 PM, Yuri Rumyantsev wrote:
> Hi Jeff!
>
> Thanks for your details comments.
>
> You asked:
> How are conditionals on vectors usually handled? You should try to
> mimick that and report, with detail, why that's not working.
>
> In current implementation of vectorizatio
Hi Jeff!
Thanks for your details comments.
You asked:
How are conditionals on vectors usually handled? You should try to
mimick that and report, with detail, why that's not working.
In current implementation of vectorization pass all comparisons are
handled through COND_EXPR, i.e. vect-pattern
On 06/18/2015 08:32 AM, Yuri Rumyantsev wrote:
Richard,
Here is updated patch which does not include your proposal related to
the target hook deletion.
You wrote:
I still don't understand why you need the new target hook. If we have a masked
load/store then the mask is computed by an assignmen
Hi Richard,
Did you have a chance to look at this updated patch?
Thanks.
Yuri.
2015-06-18 17:32 GMT+03:00 Yuri Rumyantsev :
> Richard,
>
> Here is updated patch which does not include your proposal related to
> the target hook deletion.
> You wrote:
>> I still don't understand why you need the n
Richard,
Here is updated patch which does not include your proposal related to
the target hook deletion.
You wrote:
> I still don't understand why you need the new target hook. If we have a
> masked
> load/store then the mask is computed by an assignment with a VEC_COND_EXPR
> (in your example)
On Wed, May 20, 2015 at 4:00 PM, Yuri Rumyantsev wrote:
> Hi All,
>
> Here is updated patch to optimize mask stores. The main goal of it is
> to avoid execution of mask store if its mask is zero vector since
> loads that follow it can be blocked.
> The following changes were done:
> 1. A test o
Hi Richard,
Did you have a chance to look at my updated patch?
Any comments will be appreciated.
Yuri.
2015-05-20 17:00 GMT+03:00 Yuri Rumyantsev :
> Hi All,
>
> Here is updated patch to optimize mask stores. The main goal of it is
> to avoid execution of mask store if its mask is zero vector si
Hi All,
Here is updated patch to optimize mask stores. The main goal of it is
to avoid execution of mask store if its mask is zero vector since
loads that follow it can be blocked.
The following changes were done:
1. A test on sink legality was added - it simply prohibits to cross
statements wi
On May 8, 2015 8:43:15 PM GMT+02:00, Jeff Law wrote:
>On 05/08/2015 03:27 AM, Richard Biener wrote:
>> On Wed, May 6, 2015 at 4:04 PM, Yuri Rumyantsev
>wrote:
>>> Hi All,
>>>
>>> Here is a patch which gives us significant speed-up on HASWELL for
>>> test containing masked stores. The main goal of
On 05/08/2015 03:27 AM, Richard Biener wrote:
On Wed, May 6, 2015 at 4:04 PM, Yuri Rumyantsev wrote:
Hi All,
Here is a patch which gives us significant speed-up on HASWELL for
test containing masked stores. The main goal of that patch is attempt
to avoid HW hazard for maskmove instructions thr
On Wed, May 6, 2015 at 4:04 PM, Yuri Rumyantsev wrote:
> Hi All,
>
> Here is a patch which gives us significant speed-up on HASWELL for
> test containing masked stores. The main goal of that patch is attempt
> to avoid HW hazard for maskmove instructions through inserting
> additional check on zer
Hi All,
Here is a patch which gives us significant speed-up on HASWELL for
test containing masked stores. The main goal of that patch is attempt
to avoid HW hazard for maskmove instructions through inserting
additional check on zero mask and putting all masked store statements
into separate block
33 matches
Mail list logo
