Re: [PATCH] Fix PR77826

[Richard Biener <rguenther@suse.de>]

On Thu, 6 Oct 2016, Marc Glisse wrote:

> On Wed, 5 Oct 2016, Richard Biener wrote:
> 
> > > The following will fix PR77826, the issue that in match.pd matching
> > > up two things uses operand_equal_p which is too lax about the type
> > > of the toplevel entity (at least for integer constants).
> > > 
> > > Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
> > 
> > The following is what I have applied.
> > 
> > Richard.
> > 
> > 2016-10-05  Richard Biener  <rguenther@suse.de>
> > 
> > 	PR middle-end/77826
> > 	* genmatch.c (dt_operand::gen_match_op): Amend operand_equal_p
> > 	with types_match for GIMPLE code gen to handle type mismatched
> > 	constants properly.
> 
> I don't understand the disparity between generic and gimple here. Why let
> (char)1 and (long)1 match in generic but not in gimple? And there are probably
> several transformations in match.pd that could do with an update if constants
> don't match anymore. Or did I misunderstand what the patch does?

The disparity is mostly that with GENERIC unfolded trees such as (char)1
are a bug while in GIMPLE the fact that the match.pd machinery does
valueization makes those a "feature" we have to deal with.  Originally
I've restricted GENERIC as well but with its types_match_p implementation
it resulted in too many missed matches.

I agree that some transforms would need updates - I've actually tried
to implement a warning for genmatch whenever seeing a match with
(T)@0 but there isn't any good existing place to sneak that in.

> > 	* match.pd ((X /[ex] A) * A -> X): Properly handle converted
> > 	and constant A.
> 
> This regressed
> int f(int*a,int*b){return 4*(int)(b-a);}

This is because (int)(b-a) could be a truncation in which case
multiplying with 4 might not result in the same value as
b-a truncated(?).  The comment before the unpatched patterns
said "sign-changing conversions" but nothign actually verified this.
Might be that truncations are indeed ok now that I think about it.

Btw, do you have a better suggestion as to how to handle the original
issue rather than not relying on operand_equal_p for constants?

Richard.