This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Make VRP optimize useless conversions
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Richard Guenther <rguenther at suse dot de>
- Cc: Michael Matz <matz at suse dot de>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 12 Aug 2011 16:47:12 -0700
- Subject: Re: [PATCH] Make VRP optimize useless conversions
- References: <alpine.LNX.2.00.1107071523190.810@zhemvz.fhfr.qr> <Pine.LNX.4.64.1107071750551.14485@wotan.suse.de> <alpine.LNX.2.00.1107081235080.810@zhemvz.fhfr.qr> <Pine.LNX.4.64.1107081427310.14485@wotan.suse.de> <alpine.LNX.2.00.1107081530160.810@zhemvz.fhfr.qr> <alpine.LNX.2.00.1107111412220.810@zhemvz.fhfr.qr>
On Mon, Jul 11, 2011 at 5:12 AM, Richard Guenther <rguenther@suse.de> wrote:
> On Fri, 8 Jul 2011, Richard Guenther wrote:
>
>> On Fri, 8 Jul 2011, Michael Matz wrote:
>>
>> > Hi,
>> >
>> > On Fri, 8 Jul 2011, Richard Guenther wrote:
>> >
>> > > It should be indeed safe with the current handling of conversions, but
>> > > better be safe. ?So, like the following?
>> >
>> > No. ?The point is that you can't compare the bounds that VRP computes with
>> > each other when the outcome affects correctness. ?Think about a very
>> > trivial and stupid VRP, that assigns the range [WIDEST_INT_MIN ..
>> > WIDEST_UINT_MAX] to each and every SSA name without looking at types and
>> > operations at all (assuming that this reflects the largest int type on the
>> > target). ?It's useless but correct. ?Of course we wouldn't implement such
>> > useless range discovery, but similar situations can arise when some VRP
>> > algorithms give up for certain reasons, or computation of tight bounds
>> > merely isn't implemented for some operations.
>> >
>> > Your routines need to work also in the presence of such imprecise ranges.
>> >
>> > Hence, the check that the intermediate conversion is useless needs to take
>> > into account the input value range (that's conservatively correct), and
>> > the precision and signedness of the target type (if it can represent all
>> > value of the input range the conversion was useless). ?It must not look at
>> > the suspected value range of the destination, precisely because it is
>> > conservative only.
>>
>> Ok, indeed conservative is different for what VRP does and for what
>> a transformation must assess. ?So the following patch makes
>> a conservative attempt at checking the transformation (which of
>> course non-surprisingly matches what the VRP part does).
>>
>> So, more like the following?
>
> The following actually works.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> Can you double-check it?
>
> Thanks,
> Richard.
>
> 2011-07-11 ?Richard Guenther ?<rguenther@suse.de>
>
> ? ? ? ?* tree-vrp.c (simplify_conversion_using_ranges): Manually
> ? ? ? ?translate the source value-range through the conversion chain.
>
This may have caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50066
--
H.J.