public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Richard Biener <richard.guenther@gmail.com>,
	       Ilya Enkovich <enkovich.gnu@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH, vec-tails 05/10] Check if loop can be masked
Date: Thu, 16 Jun 2016 06:26:00 -0000	[thread overview]
Message-ID: <0c14e940-8f05-f8c9-718d-f66274a864b3@redhat.com> (raw)
In-Reply-To: <CAFiYyc19Npy4EdgxvrDd5xyXK6RJfr3WuX7sEGmVsPy643mo3g@mail.gmail.com>

On 06/15/2016 05:22 AM, Richard Biener wrote:
>
> You look at TREE_TYPE of LOOP_VINFO_NITERS (loop_vinfo) - I don't think
> this is meaningful (if then only by accident).  I think you should look at the
> control IV itself, possibly it's value-range, to determine the smallest possible
> type to use.
Can we get an IV that's created after VRP?  If so, then we have to be 
prepared for the case where there's no range information on the IV.  At 
which point I think using type min/max of the IV is probably the right 
fallback.  But I do think we should be looking at range info much more 
systematically.

I can't see how TREE_TYPE of the NITERS makes sense either.

> Finally we have a related missed optimization opportunity, namely avoiding
> peeling for gaps if we mask the last load of the group (profitability depends
> on the overhead of such masking of course as it would be done in the main
> vectorized loop).
I think that's a specific instance of a more general question -- what 
transformations can be avoided by masking and can we generate costs to 
select between those transformations and masking.  Seems like a 
follow-up item rather than a requirement for this work to go forward to me.

Jeff

  reply	other threads:[~2016-06-16  6:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-19 19:43 Ilya Enkovich
2016-06-15 11:23 ` Richard Biener
2016-06-16  6:26   ` Jeff Law [this message]
2016-06-22 15:03     ` Ilya Enkovich
2016-06-22 17:20       ` Jeff Law
2016-06-16  7:08 ` Jeff Law
2016-06-22 16:09   ` Ilya Enkovich
2016-06-22 17:42     ` Jeff Law
2016-06-23  9:57       ` Ilya Enkovich
2016-06-28 14:08         ` Ilya Enkovich
2016-07-11 13:39         ` Ilya Enkovich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0c14e940-8f05-f8c9-718d-f66274a864b3@redhat.com \
    --to=law@redhat.com \
    --cc=enkovich.gnu@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).