On Thu, 9 Oct 2014, Uros Bizjak wrote:
Given that this will be a substantial work and considering the request
from Kirill, what do you think about separate development branch until
AVXn stuff is finished? This will give a couple of weeks and a
playground to finalize the approach for the conversi
On Thu, Oct 9, 2014 at 7:46 PM, Marc Glisse wrote:
>>> If this is accepted, I will gladly prepare patches removing the unused
>>> builtins and extending this to a few more operations (integer vectors in
>>> particular). If this is not the direction we want to go, I'd like to hear it
>>> clearly s
On Thu, 9 Oct 2014, Olivier Hainque wrote:
On Oct 9, 2014, at 12:33 PM, Marc Glisse wrote:
If this is accepted, I will gladly prepare patches removing the unused builtins
and extending this to a few more operations (integer vectors in particular). If
this is not the direction we want to go, I
Hello Marc,
On Oct 9, 2014, at 12:33 PM, Marc Glisse wrote:
> If this is accepted, I will gladly prepare patches removing the unused
> builtins and extending this to a few more operations (integer vectors in
> particular). If this is not the direction we want to go, I'd like to hear it
> clearl
On Thu, Oct 9, 2014 at 5:57 AM, Uros Bizjak wrote:
> On Thu, Oct 9, 2014 at 2:28 PM, Marc Glisse wrote:
>> On Thu, 9 Oct 2014, Uros Bizjak wrote:
>>
>>> On Thu, Oct 9, 2014 at 12:33 PM, Marc Glisse wrote:
Ping https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01812.html
(another
Hello folks,
On 09 Oct 14:57, Uros Bizjak wrote:
> On Thu, Oct 9, 2014 at 2:28 PM, Marc Glisse wrote:
> > On Thu, 9 Oct 2014, Uros Bizjak wrote:
> OK, let's go in the proposed way, more detailed:
>
> - we begin with +-*/ of float/double vectors. IMO, this would result
> in a relatively small and
On Thu, Oct 9, 2014 at 2:28 PM, Marc Glisse wrote:
> On Thu, 9 Oct 2014, Uros Bizjak wrote:
>
>> On Thu, Oct 9, 2014 at 12:33 PM, Marc Glisse wrote:
>>>
>>> Ping https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01812.html
>>>
>>> (another part of the discussion is around
>>> https://gcc.gnu.org/ml/g
On Thu, 9 Oct 2014, Uros Bizjak wrote:
On Thu, Oct 9, 2014 at 12:33 PM, Marc Glisse wrote:
Ping https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01812.html
(another part of the discussion is around
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02288.html )
Most people who commented seem cautiou
On Thu, Oct 9, 2014 at 12:33 PM, Marc Glisse wrote:
> Ping https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01812.html
>
> (another part of the discussion is around
> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02288.html )
>
> Most people who commented seem cautiously in favor. The least favorable
Ping https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01812.html
(another part of the discussion is around
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02288.html )
Most people who commented seem cautiously in favor. The least favorable
was Ulrich who suggested to go with it but keep the old be
Hello Marc,
On 26 Jul 19:34, Marc Glisse wrote:
> I did some AVX and AVX512F intrinsics, and it still passes the
> testsuite (on my old pre-AVX x86_64-linux-gnu).
I've performed testing of your patch using functional simulator of
AVX*. And see no regressions as well.
--
Thanks, K
On Tue, 8 Jul 2014, Kirill Yukhin wrote:
Hello Marc.
On 04 Jul 21:11, Marc Glisse wrote:
On Thu, 3 Jul 2014, Kirill Yukhin wrote:
like combining 2 shuffles unless the result is the identity. And
expanding shuffles that can be done in a single instruction works
well.
But I am happy not doing th
On Jul 8, 2014, at 4:17 AM, Jakub Jelinek wrote:
> On Tue, Jul 08, 2014 at 03:14:04PM +0400, Kirill Yukhin wrote:
On the over hand, updated in such a way intrinsic
may actually generate different instruction then intended (e.g. FMA case).
>>>
>>> It is the same with scalars, we have -ff
On Tue, Jul 08, 2014 at 03:14:04PM +0400, Kirill Yukhin wrote:
> > >On the over hand, updated in such a way intrinsic
> > >may actually generate different instruction then intended (e.g. FMA case).
> >
> > It is the same with scalars, we have -ffp-contract for that.
> Agreed.
I don't think we act
Hello Marc.
On 04 Jul 21:11, Marc Glisse wrote:
> On Thu, 3 Jul 2014, Kirill Yukhin wrote:
> like combining 2 shuffles unless the result is the identity. And
> expanding shuffles that can be done in a single instruction works
> well.
>
> But I am happy not doing them yet. To be very specific, coul
On Thu, 3 Jul 2014, Kirill Yukhin wrote:
Hello Marc,
On 28 Jun 12:42, Marc Glisse wrote:
It would enable a number of optimizations, like constant
propagation, FMA contraction, etc. It would also allow us to remove
several builtins.
This should be main motivation for replacing built-ins.
But th
Hello Marc,
On 28 Jun 12:42, Marc Glisse wrote:
> It would enable a number of optimizations, like constant
> propagation, FMA contraction, etc. It would also allow us to remove
> several builtins.
This should be main motivation for replacing built-ins.
But this approach IMHO should only be used for
On Sun, 29 Jun 2014, Ulrich Drepper wrote:
I think the Arm definitions come from a different angle. It's new,
there is no assumed semantics.
Is it that new? I thought it was implemented based on a rather precise
specification by ARM. Again, I don't really know arm.
For the x86 intrinsics
On Sat, Jun 28, 2014 at 6:53 PM, Marc Glisse wrote:
> There is always a risk, but then even with builtins I think there was a
> small risk that an RTL optimization would mess things up. It is indeed
> higher if we expose the operation to the optimizers earlier, but it would be
> a bug if an "optim
On Sat, 28 Jun 2014, Ulrich Drepper wrote:
On Sat, Jun 28, 2014 at 6:42 AM, Marc Glisse wrote:
Ping,
nobody has an opinion on this? Or some explanation why I am mistaken to
believe that #pragma target makes it safer now?
It would enable a number of optimizations, like constant propagation, F
On Sat, Jun 28, 2014 at 6:42 AM, Marc Glisse wrote:
> Ping,
>
> nobody has an opinion on this? Or some explanation why I am mistaken to
> believe that #pragma target makes it safer now?
>
> It would enable a number of optimizations, like constant propagation, FMA
> contraction, etc. It would also
Ping,
nobody has an opinion on this? Or some explanation why I am mistaken to
believe that #pragma target makes it safer now?
It would enable a number of optimizations, like constant propagation, FMA
contraction, etc. It would also allow us to remove several builtins.
On Sat, 17 May 2014, M
Ping
On Mon, 28 Apr 2014, Marc Glisse wrote:
Ping
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00590.html
(note that ARM seems to be doing the same thing for their neon intrinsics,
see Ramana's patch series posted today)
On Fri, 11 Apr 2014, Marc Glisse wrote:
Hello,
the previous discuss
Ping
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00590.html
(note that ARM seems to be doing the same thing for their neon
intrinsics, see Ramana's patch series posted today)
On Fri, 11 Apr 2014, Marc Glisse wrote:
Hello,
the previous discussion on the topic was before we added all those #
Hello,
the previous discussion on the topic was before we added all those #pragma
target in *mmintrin.h:
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00374.html
I believe that removes a large part of the arguments against it. Note that
I only did a few of the more obvious intrinsics, I am wa
Hello,
I was wondering if the new #pragma target in *mmintrin.h make this
approach more acceptable for 4.10?
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00374.html
On Sun, 7 Apr 2013, Marc Glisse wrote:
Hello,
the attached patch is very incomplete (it passes bootstrap+testsuite on
x86_64
On Tue, Apr 9, 2013 at 9:15 PM, Marc Glisse wrote:
> On Tue, 9 Apr 2013, Marc Glisse wrote:
>
>> On Tue, 9 Apr 2013, Richard Biener wrote:
>>
>>> I seem to remember discussion in the PR(s) that the intrinsics should
>>> (and do for other compilers) expand to the desired instructions even when
>>>
On Tue, 9 Apr 2013, Marc Glisse wrote:
On Tue, 9 Apr 2013, Richard Biener wrote:
I seem to remember discussion in the PR(s) that the intrinsics should
(and do for other compilers) expand to the desired instructions even when
the corresponding instruction set is disabled.
emmintrin.h starts w
On Tue, 9 Apr 2013, Jakub Jelinek wrote:
On Tue, Apr 09, 2013 at 11:08:38AM +0200, Marc Glisse wrote:
The *intrin.h files already use __extension__ to create vectors, like:
return __extension__ (__m128d){ __F, 0.0 };
but even when I remove it it does not warn with -std=c89 -pedantic.
Even w
On Tue, Apr 09, 2013 at 11:08:38AM +0200, Marc Glisse wrote:
> The *intrin.h files already use __extension__ to create vectors, like:
> return __extension__ (__m128d){ __F, 0.0 };
> but even when I remove it it does not warn with -std=c89 -pedantic.
Even with -Wsystem-headers ?
Jakub
On Tue, 9 Apr 2013, Richard Biener wrote:
On Mon, Apr 8, 2013 at 10:47 PM, Marc Glisse wrote:
On Sun, 7 Apr 2013, Marc Glisse wrote:
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_slli_epi16 (__m128i __A, int __B)
{
- return (__m128i)__buil
On Mon, Apr 8, 2013 at 10:47 PM, Marc Glisse wrote:
> On Sun, 7 Apr 2013, Marc Glisse wrote:
>
>> extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
>> __artificial__))
>> _mm_slli_epi16 (__m128i __A, int __B)
>> {
>> - return (__m128i)__builtin_ia32_psllwi128 ((__v8hi)_
On Sun, 7 Apr 2013, Marc Glisse wrote:
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_slli_epi16 (__m128i __A, int __B)
{
- return (__m128i)__builtin_ia32_psllwi128 ((__v8hi)__A, __B);
+ return (__m128i) ((__v8hi)__A << __B);
}
Actually, I
By the way, the comment in emmintrin.h in front of _mm_sqrt_sd seems
wrong:
/* Return pair {sqrt (A[0), B[1]}. */
It should be instead:
/* Return pair {sqrt (B[0]), A[1]}. */
If you agree I'll fix that independently.
--
Marc Glisse
Hello,
the attached patch is very incomplete (it passes bootstrap+testsuite on
x86_64-linux-gnu), but it raises a number of questions that I'd like to
settle before continuing.
* Is there any chance of a patch in this direction being accepted?
* May I remove the builtins (from i386.c and the
35 matches
Mail list logo
