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
On Thu, Oct 9, 2014 at 12:33 PM, Marc Glisse marc.gli...@inria.fr 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
On Thu, 9 Oct 2014, Uros Bizjak wrote:
On Thu, Oct 9, 2014 at 12:33 PM, Marc Glisse marc.gli...@inria.fr 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
On Thu, Oct 9, 2014 at 2:28 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Thu, 9 Oct 2014, Uros Bizjak wrote:
On Thu, Oct 9, 2014 at 12:33 PM, Marc Glisse marc.gli...@inria.fr wrote:
Ping https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01812.html
(another part of the discussion is around
Hello folks,
On 09 Oct 14:57, Uros Bizjak wrote:
On Thu, Oct 9, 2014 at 2:28 PM, Marc Glisse marc.gli...@inria.fr 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
On Thu, Oct 9, 2014 at 5:57 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Thu, Oct 9, 2014 at 2:28 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Thu, 9 Oct 2014, Uros Bizjak wrote:
On Thu, Oct 9, 2014 at 12:33 PM, Marc Glisse marc.gli...@inria.fr wrote:
Ping
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
clearly
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,
On Thu, Oct 9, 2014 at 7:46 PM, Marc Glisse marc.gli...@inria.fr 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
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
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
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, could you
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 actually
On Jul 8, 2014, at 4:17 AM, Jakub Jelinek ja...@redhat.com 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
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
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 Sat, Jun 28, 2014 at 6:53 PM, Marc Glisse marc.gli...@inria.fr 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
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
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,
On Sat, 28 Jun 2014, Ulrich Drepper wrote:
On Sat, Jun 28, 2014 at 6:42 AM, Marc Glisse marc.gli...@inria.fr 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
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
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,
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
On Tue, Apr 9, 2013 at 9:15 PM, Marc Glisse marc.gli...@inria.fr 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
On Mon, Apr 8, 2013 at 10:47 PM, Marc Glisse marc.gli...@inria.fr 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
On Tue, 9 Apr 2013, Richard Biener wrote:
On Mon, Apr 8, 2013 at 10:47 PM, Marc Glisse marc.gli...@inria.fr 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)
{
-
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, 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
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
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
32 matches
Mail list logo
