On 12/07/2012 04:02 PM, Marc Glisse wrote:
> 2012-12-08 Marc Glisse
>
> PR target/54855
> gcc/
> * config/i386/sse.md (_vm3): Rewrite
> pattern.
> (sse2_loadlpd, sse2_loadhpd): Use vec_merge.
> * config/i386/i386-builtin-types.def: New function types.
> * config/i386/i38
On Fri, 7 Dec 2012, Marc Glisse wrote:
On Fri, 7 Dec 2012, Richard Henderson wrote:
On 2012-12-07 09:12, Marc Glisse wrote:
but change ix86_expand_vector_set and others to generate vec_merge
and have only the vec_merge define_insn in sse.md? I guess it would
buy a large part of it. That's a p
On Fri, 7 Dec 2012, Richard Henderson wrote:
On 2012-12-07 09:12, Marc Glisse wrote:
but change ix86_expand_vector_set and others to generate vec_merge
and have only the vec_merge define_insn in sse.md? I guess it would
buy a large part of it. That's a pretty invasive change, I'll have to
try..
On 2012-12-07 09:12, Marc Glisse wrote:
> but change ix86_expand_vector_set and others to generate vec_merge
> and have only the vec_merge define_insn in sse.md? I guess it would
> buy a large part of it. That's a pretty invasive change, I'll have to
> try...
Is it really that invasive? Anyway, i
On Fri, 7 Dec 2012, Richard Henderson wrote:
On 2012-12-07 09:00, Marc Glisse wrote:
On Fri, 7 Dec 2012, Richard Henderson wrote:
On 2012-12-07 02:49, Marc Glisse wrote:
For 2-element vectors, vec_concat does seem more natural than
vec_merge. If we chose vec_merge as the canonical representa
On 2012-12-07 09:00, Marc Glisse wrote:
> On Fri, 7 Dec 2012, Richard Henderson wrote:
>
>> On 2012-12-07 02:49, Marc Glisse wrote:
>>> For 2-element vectors, vec_concat does seem more natural than
>>> vec_merge. If we chose vec_merge as the canonical representation, we
>>> should chose it for set
On Fri, 7 Dec 2012, Richard Henderson wrote:
On 2012-12-07 02:49, Marc Glisse wrote:
For 2-element vectors, vec_concat does seem more natural than
vec_merge. If we chose vec_merge as the canonical representation, we
should chose it for setting an element in a vector
(ix86_expand_vector_set) eve
On 2012-12-07 08:47, Jakub Jelinek wrote:
> That was the older proposal, the current way to trigger it is using
> the substitution attr somewhere, typically in pattern name
> - in the above case.
Ah right.
("My mind is going, Dave. I can feel it.")
r~
On Fri, Dec 07, 2012 at 08:43:05AM -0600, Richard Henderson wrote:
> > +(define_insn "_vm3"
> >[(set (match_operand:VF_128 0 "register_operand" "=x,x")
> > (vec_merge:VF_128
> > - (plusminus:VF_128
> > - (match_operand:VF_128 1 "register_operand" "0,x")
> > - (match_operand:
On 2012-12-07 02:49, Marc Glisse wrote:
> The root problem is that we model the subs[sd] instructions as taking
> a 128-bit second operand, when Intel's documentation says they take a
> 32/64-bit operand, which is an important difference for memory
> operands (and constants). Writing a pattern that
On Fri, 7 Dec 2012, Michael Zolotukhin wrote:
By the way, if we decide to have one pattern for V4SF instructions and
another for V2DF, we could try to use recently introduced define_subst
here. It won't reduce number of actual patterns (I mean number of
patterns after iterators and subst expandi
Thanks for the explanation!
By the way, if we decide to have one pattern for V4SF instructions and
another for V2DF, we could try to use recently introduced define_subst
here. It won't reduce number of actual patterns (I mean number of
patterns after iterators and subst expanding), but it could he
On Fri, 7 Dec 2012, Michael Zolotukhin wrote:
1) Does the root problem lay in the fact that even for scalar
additions we perform the addition on the whole vector and only then
drop the higher parts of the vector? I.e. to fix the test from the PR
we need to replace plus on vector mode with plus o
On Fri, Dec 7, 2012 at 7:49 AM, Michael Zolotukhin
wrote:
> Hi guys,
> Could I ask several questions just to clarify the things up?
>
> 1) Does the root problem lay in the fact that even for scalar
> additions we perform the addition on the whole vector and only then
> drop the higher parts of the
Hi guys,
Could I ask several questions just to clarify the things up?
1) Does the root problem lay in the fact that even for scalar
additions we perform the addition on the whole vector and only then
drop the higher parts of the vector? I.e. to fix the test from the PR
we need to replace plus on v
>> Yes, the approach taken in this patch looks really good to me. There
>> should be no code differences with your patch, but let's ask HJ for
>> his opinion on intrinsics header changes.
>
> Hi Kirill,
>
> Can you take a look? Thanks.
Hi guys, I like changes in intrinsics header.
Thanks, K
> could you take a look at the small simplify-rtx bit of this patch to see
> if the general approach makes sense to you?
>
> (this targets 4.9 and passes bootstrap+testsuite on x86_64-linux)
>
> The point of this transformation is to avoid writing a second define_insn
> in config/i386/sse.md as i
On Wed, 5 Dec 2012, Paolo Bonzini wrote:
Il 05/12/2012 15:22, Marc Glisse ha scritto:
+
+ /* The x86 back-end uses VEC_CONCAT to set an element in a V2DF, but
+ VEC_MERGE for scalar operations that preserve the other elements
+ of a vector. */
+ if (GET_CODE (true
Il 05/12/2012 15:22, Marc Glisse ha scritto:
> +
> + /* The x86 back-end uses VEC_CONCAT to set an element in a V2DF, but
> +VEC_MERGE for scalar operations that preserve the other elements
> +of a vector. */
> + if (GET_CODE (trueop1) == VEC_SELECT
> + && GET_MODE
2012-12-04 Marc Glisse
PR target/54855
gcc/
* simplify-rtx.c (simplify_binary_operation_1) : Replace
with VEC_MERGE.
* config/i386/sse.md (_vm3): Rewrite
pattern.
* config/i386/i386-builtin-types.def: New function types.
* config/i386/i3
On Tue, Dec 4, 2012 at 10:06 AM, Uros Bizjak wrote:
> On Tue, Dec 4, 2012 at 5:28 PM, Marc Glisse wrote:
>> On Tue, 4 Dec 2012, Marc Glisse wrote:
>>
>>> Do you agree?
>>
>>
>> Like this ? (only tested on the new testcases, and then I'd need to ask Eric
>> his opinion)
>>
>> 2012-12-04 Marc Glis
On Tue, Dec 4, 2012 at 5:28 PM, Marc Glisse wrote:
> On Tue, 4 Dec 2012, Marc Glisse wrote:
>
>> Do you agree?
>
>
> Like this ? (only tested on the new testcases, and then I'd need to ask Eric
> his opinion)
>
> 2012-12-04 Marc Glisse
>
> PR target/54855
> gcc/
> * simplify-rtx
On Tue, 4 Dec 2012, Marc Glisse wrote:
Do you agree?
Like this ? (only tested on the new testcases, and then I'd need to ask Eric
his opinion)
2012-12-04 Marc Glisse
PR target/54855
gcc/
* simplify-rtx.c (simplify_binary_operation_1) : Replace
with VEC_MERGE.
On Mon, 3 Dec 2012, Uros Bizjak wrote:
On Mon, Dec 3, 2012 at 4:34 PM, Marc Glisse wrote:
However, looking a bit more into the usage cases for these patterns,
they are only used through intrinsics with _m128 operands. While your
proposed patch makes these patterns more general (they can use 6
On Mon, Dec 3, 2012 at 4:34 PM, Marc Glisse wrote:
>> However, looking a bit more into the usage cases for these patterns,
>> they are only used through intrinsics with _m128 operands. While your
>> proposed patch makes these patterns more general (they can use 64bit
>> aligned memory), this is n
On Mon, 3 Dec 2012, Uros Bizjak wrote:
On Sun, Dec 2, 2012 at 1:30 PM, Marc Glisse wrote:
here is a patch. If it is accepted, I'll extend it to other vm patterns
(mul, div, min, max are likely candidates, but I need to check the doc).
It
passed bootstrap+testsuite on x86_64-linux.
2012-12-0
On Sun, Dec 2, 2012 at 1:30 PM, Marc Glisse wrote:
>>> here is a patch. If it is accepted, I'll extend it to other vm patterns
>>> (mul, div, min, max are likely candidates, but I need to check the doc).
>>> It
>>> passed bootstrap+testsuite on x86_64-linux.
>>>
>>>
>>> 2012-12-01 Marc Glisse
On Sun, 2 Dec 2012, Uros Bizjak wrote:
On Sat, Dec 1, 2012 at 6:27 PM, Marc Glisse wrote:
here is a patch. If it is accepted, I'll extend it to other vm patterns
(mul, div, min, max are likely candidates, but I need to check the doc). It
passed bootstrap+testsuite on x86_64-linux.
2012-12-0
On Sat, Dec 1, 2012 at 6:27 PM, Marc Glisse wrote:
> here is a patch. If it is accepted, I'll extend it to other vm patterns
> (mul, div, min, max are likely candidates, but I need to check the doc). It
> passed bootstrap+testsuite on x86_64-linux.
>
>
> 2012-12-01 Marc Glisse
>
> PR t
Hello,
here is a patch. If it is accepted, I'll extend it to other vm patterns
(mul, div, min, max are likely candidates, but I need to check the doc).
It passed bootstrap+testsuite on x86_64-linux.
2012-12-01 Marc Glisse
PR target/54855
gcc/
* config/i386/sse.md (_vm3):
On Fri, 30 Nov 2012, Uros Bizjak wrote:
For reference, we are talking about:
(define_insn "_vm3"
[(set (match_operand:VF_128 0 "register_operand" "=x,x")
(vec_merge:VF_128
(plusminus:VF_128
(match_operand:VF_128 1 "register_operand" "0,x")
(match_opera
On Fri, Nov 30, 2012 at 1:34 PM, Marc Glisse wrote:
> Hello,
>
> I experimented with the simplify-rtx transformation you suggested, see:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54855
>
> It works when the argument is a register, but not for memory (which is where
> the constant is in the te
On Sun, 14 Oct 2012, Marc Glisse wrote:
On Sun, 14 Oct 2012, Uros Bizjak wrote:
On Sat, Oct 13, 2012 at 10:52 AM, Marc Glisse wrote:
Hello,
this patch provides an alternate pattern to let combine recognize scalar
operations that preserve the high part of a vector. If the strategy is all
rig
On Sun, 14 Oct 2012, Uros Bizjak wrote:
On Sat, Oct 13, 2012 at 10:52 AM, Marc Glisse wrote:
Hello,
this patch provides an alternate pattern to let combine recognize scalar
operations that preserve the high part of a vector. If the strategy is all
right, I could do the same for more operation
On Sat, Oct 13, 2012 at 10:52 AM, Marc Glisse wrote:
> Hello,
>
> this patch provides an alternate pattern to let combine recognize scalar
> operations that preserve the high part of a vector. If the strategy is all
> right, I could do the same for more operations (mul, div, ...). Something
> simi
35 matches
Mail list logo
