This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: BImode and STORE_VALUE_FLAG


Mikael,

I haven't really tried m68k and I can't say I know anything about it but it will only be affected by this issue I am seeing if it generates instructions of the form:
(set (reg:BI ...)
     (<cmp>:BI (reg:SI ...) (const_int ...)))

If you have something like this then as soon as you expand this instruction, cse1 will (from 4.7 onwards at least) optimize this instruction away when it shouldn't.

I can give this backend a try on Tuesday when I get back to work to see if I can reproduce it (Monday is bank holiday over here).

I have a patch for it which seems to work but my tests end up falling apart somewhere else (but that bit might already be my fault).

Cheers,

Paulo Matos


On 04/05/13 11:50, Mikael Pettersson wrote:
On Fri, 3 May 2013 12:49:14 +0000, Paulo Matos <pmatos@broadcom.com> wrote:
Hello,

It seems to me there's a bug in simplify_const_relational_operation:simplify-rtx.c.
If you set STORE_VALUE_FLAG to -1, if you get to simplify_const_relational_operation
  with code: NE, mode: BImode, op0: reg, op1: const_int 0, then you end up in line
4717 calling get_mode_bounds.

get_mode_bounds will unfortunately return min:0, max:-1 for BImode and GCC proceeds
to compare val which is 0 using:
/* x != y is always true for y out of range.  */
	  if (val < mmin || val > mmax)
	    return const_true_rtx;

This simplifies the comparison to const_true_rtx in the case STORE_FLAG_VALUE is -1.
This seems flawed.

Unless there's some background reason for this to happen this seems like a bug. BImode
is a two value mode: 0 or STORE_FLAG_VALUE (according to trunc_int_to_mode), therefore
there are really no bounds and these comparisons in simplify_const_relational_operation
should take special care if dealing with BImode. Also, having max < min is strange at
best and I can imagine it can result in pretty strange behaviour if a developer assumes
max >= min, as usual.

I am interested in comments to this piece of code. I am happy to patch
simplify_const_relational_operation if you agree with what I said.

Cheers,

Paulo Matos

I can't comment on the code in question, but the backend for m68k may be affected
since it defines STORE_FLAG_VALUE as -1.  Do you have a testcase that would cause
wrong code, or a patch to cure the issue?  I'd be happy to do some testing on
m68k-linux.

/Mikael




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]