------- Additional Comments From jh at suse dot cz 2005-01-02 00:14 ------- Subject: Re: [4.0 Regression] unrecognisable insn in regclass on x86/amd64
> > ------- Additional Comments From jh at suse dot cz 2005-01-01 23:52 ------- > Subject: Re: [4.0 Regression] unrecognisable insn in regclass on x86/amd64 > > > > > ------- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01 > > 22:33 ------- > > (In reply to comment #21) > > > This is the original thread which leads to this regession: > > > > > > http://gcc.gnu.org/ml/gcc/2004-11/threads.html#00839 > > > > If you notice this works on all other targets other than x86/x86_64 which > > means that it is a latent bug > > in the x86 back-end. > the problem seems to be loop optimizer taking the > (const:SI (plus:SI (symbol_ref:SI ("foo") [flags 0x58] <var_decl > 0xb7d5e828 foo>) (const_int 8 [0x8])) > construct from REG_EQUAL note and throwing it into emit_move_insn > without any care. > > I don't think emit_move_insn is required to deal with arbitary constant > operand like this, so it seems to me that correct (and safe) way is to > prevent loop from this idea... I am testing attached patch. But we > might also teach move expander to decompose the CONST and legitimize it > as we do for usual variable references... Hmm, actually I now recall that last time we went across similar problem (cse constructing crazy CONST expression later used by loop same sick way) we decided to restrict cse to construct sane CONSTs and producing offsetted reference to TLS seems to be quite sane, so perhaps fixing it other way around is better. Here is the patch I am testing ;) Index: config/i386/i386.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v retrieving revision 1.766 diff -c -3 -p -r1.766 i386.c *** config/i386/i386.c 28 Dec 2004 05:26:23 -0000 1.766 --- config/i386/i386.c 2 Jan 2005 00:11:53 -0000 *************** ix86_expand_move (enum machine_mode mode *** 7472,7478 **** op0 = operands[0]; op1 = operands[1]; ! model = GET_CODE (op1) == SYMBOL_REF ? SYMBOL_REF_TLS_MODEL (op1) : 0; if (model) { op1 = legitimize_tls_address (op1, model, true); --- 7472,7484 ---- op0 = operands[0]; op1 = operands[1]; ! if (GET_CODE (op1) == CONST && GET_CODE (XEXP (op1, 0)) == PLUS ! && GET_CODE (XEXP (XEXP (op1, 0), 0)) == SYMBOL_REF) ! model = SYMBOL_REF_TLS_MODEL (XEXP (XEXP (op1, 0), 0)); ! else if (GET_CODE (op1) == SYMBOL_REF) ! model = SYMBOL_REF_TLS_MODEL (op1); ! else ! model = 0; if (model) { op1 = legitimize_tls_address (op1, model, true); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18910
