Richard Henderson schrieb:
On 10/06/2011 04:46 AM, Georg-Johann Lay wrote:
So here it is. Lightly tested on my target: All tests either PASS or are
UNSUPPORTED now.
Ok?
Not ok, but only because I've completely restructured the tests again.
Patch coming very shortly...
Thanks, I hope your
On 10/06/2011 04:46 AM, Georg-Johann Lay wrote:
> So here it is. Lightly tested on my target: All tests either PASS or are
> UNSUPPORTED now.
>
> Ok?
Not ok, but only because I've completely restructured the tests again.
Patch coming very shortly...
r~
Richard Guenther schrieb:
> On Thu, Oct 6, 2011 at 1:03 PM, Georg-Johann Lay wrote:
>> Richard Guenther schrieb:
>>> On Thu, Oct 6, 2011 at 12:51 PM, Georg-Johann Lay wrote:
Artem Shinkarov schrieb:
> Hi, Richard
>
> There is a problem with the testcases of the patch you have com
On Thu, Oct 06, 2011 at 12:51:54PM +0200, Georg-Johann Lay wrote:
> The following patch avoids __SIZEOF_INT__.
>
> Ok by some maintainer to commit?
That is unnecessary. You can just add
#else
int
main ()
{
return 0;
}
before the final #endif in the files instead.
Or move around the #ifdefs, so
On Thu, Oct 6, 2011 at 1:03 PM, Georg-Johann Lay wrote:
> Richard Guenther schrieb:
>> On Thu, Oct 6, 2011 at 12:51 PM, Georg-Johann Lay wrote:
>>> Artem Shinkarov schrieb:
Hi, Richard
There is a problem with the testcases of the patch you have committed
for me. The code in ev
Richard Guenther schrieb:
> On Thu, Oct 6, 2011 at 12:51 PM, Georg-Johann Lay wrote:
>> Artem Shinkarov schrieb:
>>> Hi, Richard
>>>
>>> There is a problem with the testcases of the patch you have committed
>>> for me. The code in every test-case is doubled. Could you please,
>>> apply the followi
On Thu, Oct 6, 2011 at 12:51 PM, Georg-Johann Lay wrote:
> Artem Shinkarov schrieb:
>> Hi, Richard
>>
>> There is a problem with the testcases of the patch you have committed
>> for me. The code in every test-case is doubled. Could you please,
>> apply the following patch, otherwise it would fail
Artem Shinkarov schrieb:
> Hi, Richard
>
> There is a problem with the testcases of the patch you have committed
> for me. The code in every test-case is doubled. Could you please,
> apply the following patch, otherwise it would fail all the tests from
> the vector-shuffle-patch would fail.
>
> A
On 10/04/2011 08:18 AM, Artem Shinkarov wrote:
> Ping.
>
> Richard, the patch in the attachment should be submitted asap. The
> other problem could wait for a while.
The patch in the attachment is wrong too. I've re-written the x86
backend support, adding TARGET_XOP in the process. I've also re
Ping.
Richard, the patch in the attachment should be submitted asap. The
other problem could wait for a while.
Thanks,
Artem.
On Tue, Oct 4, 2011 at 12:04 AM, Artem Shinkarov
wrote:
> On Mon, Oct 3, 2011 at 6:12 PM, Richard Henderson wrote:
>> On 10/03/2011 09:43 AM, Artem Shinkarov wrote:
>>>
On Fri, 30 Sep 2011, Artem Shinkarov wrote:
> gcc/doc
> * extend.texi: Adjust.
Pretty please document the new pattern names in doc/md.texi as
well. Thanks in advance.
brgds, H-P
On Fri, Sep 30, 2011 at 4:21 PM, Artem Shinkarov
wrote:
> Sorry for that, the vector comparison was submitted earlier. In the
> attachment there is a new version of the patch against the latest
> checkout.
>
> Richard, can you have a look at the genopinit.c, I am using
> set_direct_optab_handler,
On Mon, Oct 3, 2011 at 6:12 PM, Richard Henderson wrote:
> On 10/03/2011 09:43 AM, Artem Shinkarov wrote:
>> Hi, Richard
>>
>> There is a problem with the testcases of the patch you have committed
>> for me. The code in every test-case is doubled. Could you please,
>> apply the following patch, ot
On Mon, Oct 3, 2011 at 6:12 PM, Richard Henderson wrote:
> On 10/03/2011 09:43 AM, Artem Shinkarov wrote:
>> Hi, Richard
>>
>> There is a problem with the testcases of the patch you have committed
>> for me. The code in every test-case is doubled. Could you please,
>> apply the following patch, ot
On 10/03/2011 09:43 AM, Artem Shinkarov wrote:
> Hi, Richard
>
> There is a problem with the testcases of the patch you have committed
> for me. The code in every test-case is doubled. Could you please,
> apply the following patch, otherwise it would fail all the tests from
> the vector-shuffle-pa
,2,1};
-const vector (4, int) cmask = {0,3,2,1};
-register vector (4, int) rmask = {0,3,2,1};
-v4si dmask = {0,3,2,1};
-v4sicst dcmask = {0,3,2,1};
-
-test_compat (res, vec, mask);
-
-return 0;
-}
-
-/* Test that different type variants are compatible within
- vector shuffling.
On 10/03/2011 05:14 AM, Artem Shinkarov wrote:
> Hi, can anyone commit it please?
>
> Richard?
> Or may be Richard?
Committed.
r~
Hi, can anyone commit it please?
Richard?
Or may be Richard?
Thanks,
Artem.
On Sat, Oct 1, 2011 at 12:21 AM, Artem Shinkarov
wrote:
> Sorry for that, the vector comparison was submitted earlier. In the
> attachment there is a new version of the patch against the latest
> checkout.
>
> Richar
On 09/30/2011 12:14 PM, Artem Shinkarov wrote:
> Ok, in the attachment there is a patch which fixes mentioned errors.
The changes are ok. I would have committed it for you, only the patch
isn't against mainline. There are 4 rejects.
r~
> I hope that the new version looks a little bit better.
Nearly ok. Some trivial fixes, and then please commit.
> + rtx_v0 = expand_normal (v0);
> + rtx_mask = expand_normal (mask);
> +
> + create_output_operand (&ops[0], target, mode);
> + create_input_operand (&ops[3], rtx_mask, mode);
> +
On 09/29/2011 03:44 AM, Artem Shinkarov wrote:
> Here is a new version of the patch which hopefully fixes all the
> formatting issues and uses expand_simple_binop instead of force_reg in
> binary operations.
>
> Ok?
Well, it's certainly not perfect by any means. But I guess I can fix
things up m
On 09/28/2011 05:59 AM, Artem Shinkarov wrote:
> I don't really understand this. As far as I know, expand_normal
> "converts" tree to rtx. All my computations are happening at the level
> of rtx and force_reg is needed just to bring an rtx expression to the
> register of the correct mode. If I am m
On Thu, Sep 15, 2011 at 8:05 PM, Richard Henderson wrote:
>> +The elements of the input vectors are numbered from left to right across
>> +one or both of the vectors. Each element in the mask specifies a number
>> +of element from the input vector(s). Consider the following example.
>
> It would b
> +The elements of the input vectors are numbered from left to right across
> +one or both of the vectors. Each element in the mask specifies a number
> +of element from the input vector(s). Consider the following example.
It would be more preferable to talk about the memory ordering of the
elemen
On Fri, 9 Sep 2011, Artem Shinkarov wrote:
> Hi, sorry for the delay, I had a lot of other stuff to do.
>
> In the attachment there is a new patch that fixes all the issues
> pointed by Joseph and almost all the issues pointed by Richard. The
> issues that are not fixed are explained further.
Th
On Fri, Sep 9, 2011 at 5:51 PM, Artem Shinkarov
wrote:
> Hi, sorry for the delay, I had a lot of other stuff to do.
>
> In the attachment there is a new patch that fixes all the issues
> pointed by Joseph and almost all the issues pointed by Richard. The
> issues that are not fixed are explained f
On Sat, 3 Sep 2011, Artem Shinkarov wrote:
> > No. ?You need to fold it (c_fully_fold) to eliminate any
> > C_MAYBE_CONST_EXPR it contains, but you shouldn't need to wrap the result
> > of folding in a SAVE_EXPR.
>
> Ok, Now I get it, thanks.
>
> In the attachment there is a new version of the p
On Sat, Sep 3, 2011 at 5:52 PM, Artem Shinkarov
wrote:
> On Fri, Sep 2, 2011 at 8:52 PM, Joseph S. Myers
> wrote:
>> On Fri, 2 Sep 2011, Artem Shinkarov wrote:
>>
>>> Joseph, I don't understand this comment. I have 2 or 3 arguments in
>>> the VEC_SHUFFLE_EXPR and any of them can be C_MAYBE_CONST
On Fri, 2 Sep 2011, Artem Shinkarov wrote:
> Joseph, I don't understand this comment. I have 2 or 3 arguments in
> the VEC_SHUFFLE_EXPR and any of them can be C_MAYBE_CONST_EXPR,
Yes.
> so I
> need to wrap mask (the last argument) to avoid the following failure:
No. You need to fold it (c_full
On Fri, Sep 2, 2011 at 4:41 PM, Joseph S. Myers wrote:
> On Fri, 2 Sep 2011, Artem Shinkarov wrote:
>
>> + /* Avoid C_MAYBE_CONST_EXPRs inside VEC_SHUFFLE_EXPR. */
>> + tmp = c_fully_fold (v0, false, &maybe_const);
>> + v0 = save_expr (tmp);
>> + wrap &= maybe_const;
>
> I suppose you need th
On Fri, 2 Sep 2011, Artem Shinkarov wrote:
> + /* Avoid C_MAYBE_CONST_EXPRs inside VEC_SHUFFLE_EXPR. */
> + tmp = c_fully_fold (v0, false, &maybe_const);
> + v0 = save_expr (tmp);
> + wrap &= maybe_const;
I suppose you need this save_expr because of the two-argument case, but
shouldn't need
On Wed, 31 Aug 2011, Artem Shinkarov wrote:
> On Wed, Aug 31, 2011 at 4:38 PM, Joseph S. Myers
> wrote:
> > On Wed, 31 Aug 2011, Artem Shinkarov wrote:
> >
> >> 1) Helper function for the pseudo-builtins.
> >> In my case the builtin can have 2 or 3 arguments, and I think that I
> >> expressed tha
On Aug 31, 2011, at 1:27 AM, Artem Shinkarov wrote:
>> If you're going to add vector shuffling builtins, you might consider adding
>> the same builtin that clang has for compatibility:
>> http://clang.llvm.org/docs/LanguageExtensions.html#__builtin_shufflevector
>&
On Wed, Aug 31, 2011 at 4:38 PM, Joseph S. Myers
wrote:
> On Wed, 31 Aug 2011, Artem Shinkarov wrote:
>
>> 1) Helper function for the pseudo-builtins.
>> In my case the builtin can have 2 or 3 arguments, and I think that I
>> expressed that in a pretty much short way without any helper function.
>
On Wed, 31 Aug 2011, Artem Shinkarov wrote:
> 1) Helper function for the pseudo-builtins.
> In my case the builtin can have 2 or 3 arguments, and I think that I
> expressed that in a pretty much short way without any helper function.
> Am I missing something?
The point is to refactor what's commo
On Wed, Aug 31, 2011 at 1:02 PM, Artem Shinkarov
wrote:
> Here is a newer version of the patch, which transforms the builtin to
> the VEC_SHUFFLE_EXPR in the front-end.
>
> Several comments:
> 1) Helper function for the pseudo-builtins.
> In my case the builtin can have 2 or 3 arguments, and I thi
Middle-end parts seems to be more or less fine, they have not changed
>>>>>> much from the previous time.
>>>>>
>>>>> +@code{__builtin_shuffle (vec, mask)} and
>>>>> +@code{__builtin_shuffle (vec0, vec1, mask)}. Both functions construct
was the syntax we agreed on that elegantly handles both cases in one place.
If you're going to add vector shuffling builtins, you might consider adding the
same builtin that clang has for compatibility:
http://clang.llvm.org/docs/LanguageExtensions.html#__builtin_shufflevector
It shou
sk)}. Both functions construct
>>>
>>> the latter would be __builtin_shuffle2.
>>
>> Why??
>> That was the syntax we agreed on that elegantly handles both cases in one
>> place.
>
> If you're going to add vector shuffling builtins, you migh
sk)}. Both functions construct
>>>
>>> the latter would be __builtin_shuffle2.
>>
>> Why??
>> That was the syntax we agreed on that elegantly handles both cases in one
>> place.
>
> If you're going to add vector shuffling builtins, you might consi
On Tue, Aug 30, 2011 at 7:01 PM, Artem Shinkarov
wrote:
> On Tue, Aug 30, 2011 at 2:03 PM, Richard Guenther
> wrote:
>> On Tue, Aug 30, 2011 at 4:31 AM, Artem Shinkarov
>> wrote:
>>> Hi
>>>
>>> This is a patch for the explicit vector shuffli
t;
> Why??
> That was the syntax we agreed on that elegantly handles both cases in one
> place.
If you're going to add vector shuffling builtins, you might consider adding the
same builtin that clang has for compatibility:
http://clang.llvm.org/docs/LanguageExtensions.html#__builtin_shufflevector
It should be straight-forward to map it into the same IR.
-Chris
On Tue, Aug 30, 2011 at 2:03 PM, Richard Guenther
wrote:
> On Tue, Aug 30, 2011 at 4:31 AM, Artem Shinkarov
> wrote:
>> Hi
>>
>> This is a patch for the explicit vector shuffling we have discussed a
>> long time ago here:
>> http://gcc.gnu.org/ml/gcc-patches
On Tue, 30 Aug 2011, Richard Guenther wrote:
> oh, hum - now I remember ;) Eventually the C frontend should handle
> this not via the function call mechanism but similar to how Joseph
> added __builtin_complex support with
>
> 2011-08-19 Joseph Myers
>
> * c-parser.c (c_parser_postfi
On Tue, Aug 30, 2011 at 4:31 AM, Artem Shinkarov
wrote:
> Hi
>
> This is a patch for the explicit vector shuffling we have discussed a
> long time ago here:
> http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01092.html
>
> The new patch introduces the new tree code, as we agree
Hi
This is a patch for the explicit vector shuffling we have discussed a
long time ago here:
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01092.html
The new patch introduces the new tree code, as we agreed, and expands
this code by checking the vshuffle pattern in the backend.
The patch at the
46 matches
Mail list logo
