[Bug target/44073] New: x86 constants could be unduplicated

[Bug target/44073] New: x86 constants could be unduplicated

[astrange at ithinksw dot com]

void f1(int *a, int *b, int *c)
{
    int d = 0xE0E0E0E0;

    *a = *b = *c = d;
}

produces
_f1:
LFB0:
        movl    $-522133280, (%rdx)
        movl    $-522133280, (%rsi)
        movl    $-522133280, (%rdi)
        ret

on x86-64 at -Os. It would save instruction space and probably not be any
slower to actually assign d to a register, but this is only done for 64-bit
constants.


-- 
           Summary: x86 constants could be unduplicated
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: astrange at ithinksw dot com
  GCC host triplet: x86_64-*-*


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

[Bug target/44073] x86 constants could be unduplicated

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2010-05-11 08:42 -------
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-05-11 08:42:34
               date|                            |


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

[Bug target/44073] x86 constants could be unduplicated

[steven at gcc dot gnu dot org]

------- Comment #2 from steven at gcc dot gnu dot org  2010-05-11 10:24 -------
There is a GIMPLE uncprop pass for this. Could you verify that after this pass
there is just one assignment of the constant to an SSA_NAME? If so, the problem
is in the RTL CPROP pass, otherwise we have to look at the GIMPLE pass first.


-- 


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

[Bug target/44073] x86 constants could be unduplicated

[astrange at ithinksw dot com]

------- Comment #3 from astrange at ithinksw dot com  2010-05-11 10:36 -------
It's propagated by vrp1, and then nothing removes it again. tree-uncprop
doesn't change it - it looks like it doesn't have anything to handle this,
actually.


-- 


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

[Bug target/44073] x86 constants could be unduplicated

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2010-07-24 21:37 -------
CSE/GCSE should be doing it.  Oh but CSE does not handle RTL like:
(insn 8 5 9 2 t.c:5 (set (mem:SI (reg/v/f:DI 60 [ c ]) [2 *c_2(D)+0 S4 A32])
        (const_int -522133280 [0xffffffffe0e0e0e0])) 63 {*movsi_internal}
(nil))

Related to PR 23488.

What happens if you revert:
2005-07-30  Jan Hubicka  <jh@suse.cz>

        * expr.c (expand_expr_real_1): Do not load mem targets into register.
        * i386.c (ix86_fixup_binary_operands): Likewise.
        (ix86_expand_unary_operator): Likewise.
        (ix86_expand_fp_absneg_operator): Likewise.
        * optabs.c (expand_vec_cond_expr): Validate dest.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   GCC host triplet|x86_64-*-*                  |
 GCC target triplet|                            |x86_64-*-*


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

[Bug target/44073] x86 constants could be unduplicated

[astrange at ithinksw dot com]

------- Comment #5 from astrange at ithinksw dot com  2010-08-08 06:39 -------
That commit doesn't reverse cleanly anymore, and I'm not sure how to update it.
I don't have any pre-2005 gccs at the moment to test with.


-- 


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