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 <rguent...@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.
