This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR81503 (SLSR invalid fold)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Biener <richard dot guenther at gmail dot com>
- Date: Thu, 3 Aug 2017 18:39:50 +0200
- Subject: Re: [PATCH] Fix PR81503 (SLSR invalid fold)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jakub at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 807368123F
- References: <7bd4dcbb-cce0-82bb-b938-ffd85dd0e72a@linux.vnet.ibm.com> <20170803162022.GB2123@tucnak> <AC8B3792-9F2D-4C03-9331-2DB32D7A09A7@linux.vnet.ibm.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Aug 03, 2017 at 11:29:44AM -0500, Bill Schmidt wrote:
> > And, wouldn't it be more readable to use:
> > && (TYPE_UNSIGNED (target_type)
> > ? (wi::eq_p (bump, wi::zext (bump, prec))
> > || wi::eq_p (bump + wi::to_widest (maxval) + 1,
> > wi::zext (bump, prec)))
> > : wi::eq_p (bump, wi::sext (bump, prec)))
> > ?
>
> Probably. As noted, it's all becoming a bit unreadable with too
> much negative logic in a long conditional, so I want to clean that
> up in a follow-up.
>
> > For TYPE_UNSIGNED, do you actually need any restriction?
> > What kind of bump values are wrong for unsigned types and why?
>
> If the value of the bump is actually larger than the precision of the
> type (not likely except for quite small types), say 2 * (maxval + 1)
> which is congruent to 0, the replacement is wrong.
Ah, ok. Anyway, for unsigned type, perhaps it could be written as:
&& (TYPE_UNSIGNED (target_type)
? wi::eq_p (wi::neg_p (bump) ? bump + wi::to_widest (maxval) + 1
: bump, wi::zext (bump, prec))
: wi::eq_p (bump, wi::sext (bump, prec)))
I mean, if bump >= 0, then the bump + wi::to_widest (maxval) + 1
value has no chance to be equal to zero extended bump, and
for bump < 0 only that one has a chance.
Jakub