This is the mail archive of the gcc-patches@gcc.gnu.org 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: RFC: Gimple combine/folding interface


On Mon, Jul 22, 2013 at 01:36:17PM -0600, Jeff Law wrote:
> Before designing an interface which inherently includes that
> information we should think hard about if it's valuable and if a
> tree combiner is the right place.
> 
> I have high hopes that we can get the zero/sign extension
> elimination we want by carrying VRP information and querying it.
> 
> As Richi has mentioned, we really want a folder we can call
> independently of whatever pass we're in.  Though I'd also like a
> folder that can query for pass specific information if it's handy
> and useful.

For the preservation of VRP info we already have patch in process of review:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00121.html

As for zero bits info, I've recently run into a case where having the zero
bits information preserved alongside of the VRP info could be helpful,
for optimizing away the vectorizer scalar loop for bound.  If non-zero bits
computation proves or e.g. user asserts through if (val % 32)
__builtin_unreachable () or similar, even when the bounds of the loop aren't
constant, we could figure out that the number of iterations is a multiply of
vectorization factor and avoid computing that

So, perhaps let vrp{1,2} compute the vrp info and preserve (plus if not
specified just set nonzero bits to all ones), and this pass or other compute
the nonzero bits?  Sign bit copies is just an int, perhaps also track that.

	Jakub


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