This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Small ubsan vector arith optimization to fix one testcase from PR sanitizer/79904
- From: Richard Biener <rguenther at suse dot de>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 8 Mar 2017 11:03:53 +0100 (CET)
- Subject: Re: [PATCH] Small ubsan vector arith optimization to fix one testcase from PR sanitizer/79904
- Authentication-results: sourceware.org; auth=none
- References: <20170307185802.GQ22703@tucnak> <alpine.LSU.2.20.1703080910440.30051@zhemvz.fhfr.qr> <20170308091037.GX22703@tucnak>
On Wed, 8 Mar 2017, Jakub Jelinek wrote:
> On Wed, Mar 08, 2017 at 09:15:05AM +0100, Richard Biener wrote:
> > Ok. Note that another option for the loopy case is to do
> >
> > for (;;)
> > {
> > vec >> by-one-elt;
> > elt = BIT_FIELD_REF <vec, index-zero>;
> > }
>
> Indeed, that is a possibility, but I guess I'd need to construct
> the result similarly if resv is non-NULL. Also, not sure about big endian
> vectors and whether BIT_FIELD_REF with zero or size - elt_size is
> more efficient there.
>
> In any case, the PR was about s390 without vectors enabled, so this wouldn't
> apply.
>
> > when whole-vector shifts are available (they are constructed by
> > VEC_PERM_EXPR if vec_perm_const_ok for that mask). If you end up
> > doing variable-index array accesses you can as well spill the
> > vector to memory and use memory accesses on that. Not sure how
> > to arrange that from this part of the expander.
>
> Shouldn't something else during the expansion force it into memory if it is
> more efficient to expand it that way? Apparently it is forced into memory
Possibly - but it might end up spilling in the loop itself and thus be
rather inefficient?
> on s390 and the ICE is that the backend doesn't like something on it.
Could be - as I said I didn't look into what the ICE actually is.
Richard.