This is the mail archive of the 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: Need help with PR71976 combine.c::get_last_value returns a wrong result

On Wed, Jul 27, 2016 at 09:14:27PM +0200, Georg-Johann Lay wrote:
> >diff --git a/gcc/combine.c b/gcc/combine.c
> >index 77e0d2b..dec6226 100644
> >--- a/gcc/combine.c
> >+++ b/gcc/combine.c
> >@@ -9977,6 +9977,9 @@ reg_num_sign_bit_copies_for_combine (const_rtx x, 
> >machine_mode mode,
> >       return NULL;
> >     }
> > 
> >+  if (GET_MODE_PRECISION (rsp->last_set_mode) != GET_MODE_PRECISION 
> >(mode))
> >+    return NULL;
> >+
> >   tem = get_last_value (x);
> >   if (tem != 0)
> >     return tem;
> But the problem is inside get_last_value.  You'd have to add such a 
> check at /all/ call sites of that function.  Using a value for a hard 
> reg that's been set in a smaller mode than the mode of get_last_value is 
> just wrong.

Things like nonzero_bits explicitly deal with it.  For MODE_INT values
at least; the code looks a bit shaky.

> For example combine tracks bits which are known to be zero, and if 
> get_last_value is used in a similar situation, then the conclusion about 
> zero-bits is also wrong.

How so?  I don't see it.

> Would be interesting to patch get_last_value so that it issues some 
> diagnostic if
>     && (GET_MODE_PRECISION (rsp->last_set_mode)
>         < GET_MODE_PRECISION (GET_MODE (x))))
> and then run the testsuite against that compiler.  I would expect that 
> the condition doesn't even trigger on x86.

Why restrict this to hard regs at all?  Yes I know it isn't supposed
to happen for pseudos, but that also means you do not need to check?


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