This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 2/2] Enable elimination of zext/sext
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Kugan <kugan dot vivekanandarajah at linaro dot org>
- Cc: Uros Bizjak <ubizjak at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>
- Date: Fri, 5 Sep 2014 11:50:56 +0200
- Subject: Re: [PATCH 2/2] Enable elimination of zext/sext
- Authentication-results: sourceware.org; auth=none
- References: <CAFULd4aAN3KnSHzNyLckHiNBj1wiwNvih9hCymP8fbWmiNNA9g at mail dot gmail dot com> <CAFiYyc0jnw=F-te2Ba1b77cak3_VofY7SEgYBMpTGgTtVRkJzQ at mail dot gmail dot com> <53FEDF34 dot 4090605 at linaro dot org> <CAFiYyc2-Z6TpJfMbkRF2eki=qoCjJywzR1gJZKX9oZ+bh0enow at mail dot gmail dot com> <5407DF57 dot 2040902 at linaro dot org> <CAFiYyc0D22fh2Votpebb=+oxPenJ9UznQYkeX8MRMLe0aTbPqw at mail dot gmail dot com> <540912E1 dot 30505 at linaro dot org>
On Fri, Sep 5, 2014 at 3:33 AM, Kugan <kugan.vivekanandarajah@linaro.org> wrote:
>>> Here is an attempt to do the value range computation in promoted_mode's
>>> type when it is overflowing. Bootstrapped on x86-84.
>>
>> Err - I think you misunderstood this as a suggestion to do this ;)
>> value-ranges should be computed according to the type not according
>> to the (promoted) mode. Otherwise we will miss optimization
>> opportunities.
>
> Oops, sorry, I had my doubts about making trees aware of back-end stuff.
>
> Coming back to the original problem, what would be the best approach to
> handle this. Looking at the VRP pass, it seems to me that only MULT_EXPR
> and LSHIFT_EXPR are truncating values this way. All other operation are
> setting it to type_min, type_max. Can we rely on this ?
No, that doesn't sound like a good thing to do.
> Is this error not showing up in PROMOTED_MODE <= word_mode (and
> the mode precision of register from which we SUBREG is <= word_mode
> precision) is just a coincidence. Can we rely on this?
Sounds like a coincidence to me.
> Is there anyway we can fix this?
Well - the best way would be to expose the target specifics to GIMPLE
at some point in the optimization pipeline. My guess would be that it's
appropriate after loop optimizations (but maybe before induction variable
optimization).
That is, have a pass that applies register promotion to all SSA names
in the function, inserting appropriate truncations and extensions. That
way you'd never see (set (subreg...) on RTL. The VRP and DOM
passes running after that pass would then be able to aggressively
optimize redundant truncations and extensions.
Effects on debug information are to be considered. You can change
the type of SSA names in-place but you don't want to do that for
user DECLs (and we can't have the SSA name type and its DECL
type differ - and not sure if we might want to lift that restriction).
Richard.
> Thanks again,
> Kugan
>
>
>