Re: [PATCH] Fix (intptr_t) x eq/ne CST to x eq/ne (typeof x) cst match.pd pattern (PR tree-optimization/85446)

[Marc Glisse <marc dot glisse at inria dot fr>]

On Thu, 19 Apr 2018, Jakub Jelinek wrote:

> As mentioned in the PR, this optimization can't work if @0's precision
> is higher than @1's precision, because originally it compares just some set
> of lower bits, but in the new comparison compares all bits.
> If @0's precision is smaller than @1's precision (in this case @0 can't be
> a pointer, as we disallow such direct casts), then in theory it can be
> handled, but will not match what the comment says and we'd need to verify
> that the @1 constant can be represented in the @0's precision.
>
> This patch just verifies the precision is the same and does small formatting
> cleanup.  Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?

That certainly seems safe, but I am surprised to see a direct cast from 
64-bit pointer to 32-bit integer. I've always seen gcc represent those 
with an intermediate cast to a 64-bit integer, even if 
verify_gimple_assign_unary allows the direct cast. Does it depend on the 
platform? It might be nice to canonicalize this a bit, either by 
forbidding narrowing pointer-to-integer casts, or by simplifying cast 
chains to direct casts.

--
Marc Glisse