[Bug target/55894] New: No constant propagation in Intel intrinsics

[Bug target/55894] New: No constant propagation in Intel intrinsics

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55894

             Bug #: 55894
           Summary: No constant propagation in Intel intrinsics
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: glisse@gcc.gnu.org
            Target: x86_64-linux-gnu


I was comparing ways to generate a constant (Intel 12.0 doesn't support the
first one), and noticed that these functions result in different asm. In
particular, there doesn't seem to be a lot of constant propagation going on :-(
-Ofast and various -march only managed to change 'g' to movddup    .LC1(%rip),
%xmm0 (which in itself looks better than movapd, except that if I change g to
take an argument __m128d a and return _mm_xor_pd(a,m), that prevents gcc from
compacting it to a single insn, and I really don't see a reason for f and g to
generate different code as they look so similar). By the way, if you have a
suggestion on the simplest portable way to get this constant...

#include <x86intrin.h>
__m128d f(){
  const __m128d m = _mm_castsi128_pd (_mm_set1_epi64x (0x7fffffffffffffff));
  return m;
}
__m128d g(){
  const __m128d m = _mm_castsi128_pd (_mm_set1_epi64
(_mm_set_pi32(0x7fffffff,0xffffffff)));
  return m;
}
__m128d h(){
  const __m128d x = _mm_set1_pd (-0.);
  const __m128d m1 = _mm_cmpeq_pd (x, x);
  const __m128d m = _mm_xor_pd (x, m1);
  return m;
}

_Z1fv:
.LFB539:
    .cfi_startproc
    movapd    .LC0(%rip), %xmm0
    ret
    .cfi_endproc
[...]
_Z1gv:
.LFB540:
    .cfi_startproc
    movq    .LC1(%rip), %xmm0
    punpcklqdq    %xmm0, %xmm0
    ret
    .cfi_endproc
[...]
_Z1hv:
.LFB541:
    .cfi_startproc
    movapd    .LC3(%rip), %xmm0
    movapd    %xmm0, %xmm1
    cmpeqpd    %xmm0, %xmm1
    xorpd    %xmm1, %xmm0
    ret
    .cfi_endproc
[...]
.LC0:
    .long    4294967295
    .long    2147483647
    .long    4294967295
    .long    2147483647
    .section    .rodata.cst8,"aM",@progbits,8
    .align 8
.LC1:
    .long    -1
    .long    2147483647
    .section    .rodata.cst16
    .align 16
.LC3:
    .long    0
    .long    -2147483648
    .long    0
    .long    -2147483648

[Bug target/55894] No constant propagation in Intel intrinsics

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55894

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-01-07
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-07 13:36:15 UTC ---
Usually target built-in folders are missing (targetm.fold_builtin).

[Bug target/55894] No constant propagation in Intel intrinsics

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55894

--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> 2013-01-07 13:48:17 UTC ---
(In reply to comment #1)
> Usually target built-in folders are missing (targetm.fold_builtin).

That's one possibility. But I was wondering (and almost filed it in
rtl-optimization) why the folding was not already happening in RTL. The
builtins are expanded to standard vec_duplicate, eq, xor.

[Bug target/55894] No constant propagation in Intel intrinsics

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55894

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-07 14:25:33 UTC ---
The reason why it doesn't happen during combine is that the insns don't allow
constants, they require loads from memory, so while the compiler is aware
of the folded constant, e.g. in the g function:
(insn 12 7 15 2 (set (reg/i:V2DF 21 xmm0)
        (subreg:V2DF (reg:V2DI 65 [ D.4526 ]) 0)) pr55894.c:16 1157
{*movv2df_internal}
     (expr_list:REG_DEAD (reg:V2DI 65 [ D.4526 ])
        (expr_list:REG_EQUAL (const_vector:V2DF [
                    (const_double:DF +QNaN [+QNaN])
                    (const_double:DF +QNaN [+QNaN])
                ])
            (nil))))
it fails to match and thus isn't actually used in the code.  A pass that would
see you load a constant from memory, do some transformations on it which are
all foldable by the compiler and transforming that into just load of a
different constant could handle this (or do it in combine?), but the problem
with that is that it could in theory increase the constant pool too much.

[Bug target/55894] No constant propagation in Intel intrinsics

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55894

--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> 2013-01-07 20:17:15 UTC ---
Two more versions:

__m128d f(){
  union { long long t[2]; __m128d d; } a
    = {{ 0x7fffffffffffffff, 0x7fffffffffffffff }};
  return a.d;
}

_Z1fv:
.LFB537:
    .cfi_startproc
    movabsq    $9223372036854775807, %rax
    movq    %rax, -24(%rsp)
    movq    %rax, -16(%rsp)
    movapd    -24(%rsp), %xmm0
    ret
    .cfi_endproc

__m128d g(){
  union { long long l; double d; } b;
  b.l = 0x7fffffffffffffff;
  return _mm_set1_pd(b.d);
}

_Z1gv:
.LFB538:
    .cfi_startproc
    movapd    .LC0(%rip), %xmm0
    ret
    .cfi_endproc

I'll hope that other compilers also optimize this last version and use that
one.

[Bug target/55894] No constant propagation in Intel intrinsics

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55894

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
           Severity|normal                      |enhancement

[Bug target/55894] No constant propagation in Intel intrinsics

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55894

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2013-01-07 00:00:00         |2021-12-28

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
For g:
  _5 = __builtin_ia32_vec_init_v2si (-1, 2147483647);