This is the mail archive of the
mailing list for the GCC project.
Re: [RFA][PATCH][PR rtl-optimization/47477] Type narrowing in match.pd
- From: Jeff Law <law at redhat dot com>
- To: "Bin.Cheng" <amker dot cheng at gmail dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 12 Feb 2015 09:43:16 -0700
- Subject: Re: [RFA][PATCH][PR rtl-optimization/47477] Type narrowing in match.pd
- Authentication-results: sourceware.org; auth=none
- References: <54DA7029 dot 4070001 at redhat dot com> <CAHFci2-vN0t4M+YWGJDFgxc_HNNArFkOdjFPMYjE3Q=Bdc9F9A at mail dot gmail dot com>
On 02/12/15 00:01, Bin.Cheng wrote:
match.pd really feels like a meta-language which describes how to
combine gimple or generic statements.
Cool that we are trying to simplify type conversion using generic
match facility. I have thought about type promotion in match.pd too.
In theory, given VRP information attached to an SSA_NAME you could query
that information in the conditional part of the match.pd pattern.
For example, (unsigned long long)(unsigned long)(int_expr), if we can
prove int_expr is always positive (in my case, this is from vrp
information), then the first conversion can be saved. This is another
way for (and related? I didn't look at the code) the sign/zero
extension elimination work using VRP I suppose?
Another patch I'm working on is best described as detecting cases where
an outer bit-and masks off all the bits outside the innermost operand's
type. Under the right conditions, this also allows for narrowing.