This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Move some bit and binary optimizations in simplify and match
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, "Hurugalawadi, Naveen" <Naveen dot Hurugalawadi at caviumnetworks dot com>
- Date: Wed, 14 Oct 2015 13:38:02 +0200 (CEST)
- Subject: Re: Move some bit and binary optimizations in simplify and match
- Authentication-results: sourceware.org; auth=none
- References: <SN2PR0701MB10242B9E56933B072C29DE698E360 at SN2PR0701MB1024 dot namprd07 dot prod dot outlook dot com> <CAFiYyc0hiJX=Q6q9b4cNBnNXaKWKPkk3tb4gaBZr_m-gU9OjCA at mail dot gmail dot com> <SN2PR0701MB10245F3B91BE5291AD40C1848E310 at SN2PR0701MB1024 dot namprd07 dot prod dot outlook dot com> <CAFiYyc12AuTFeiB5WkQEdzPf_3vSaQyV6UdWsXNSYP8H+91p_g at mail dot gmail dot com> <SN2PR0701MB102426DA4DC98FDCB8428FB28E300 at SN2PR0701MB1024 dot namprd07 dot prod dot outlook dot com> <CAFiYyc3PEDejBG+3kyYoHm2W7tQKmDd+PSw58me4Zjieij2+fg at mail dot gmail dot com> <alpine dot DEB dot 2 dot 20 dot 1510131413240 dot 2213 at laptop-mg dot saclay dot inria dot fr> <CAFiYyc1yG0xPACvMMHn1oar+MgOE_qER3aFgZNr9KuDeaavoLQ at mail dot gmail dot com> <SN2PR0701MB10249F42F47E03257133DAF78E3F0 at SN2PR0701MB1024 dot namprd07 dot prod dot outlook dot com> <alpine dot DEB dot 2 dot 20 dot 1510140733470 dot 1981 at laptop-mg dot saclay dot inria dot fr> <CAFiYyc0GqkXkbqAEAh5_ivgGHQb2YNzRukmGduio-dHp7RbQjQ at mail dot gmail dot com> <alpine dot DEB dot 2 dot 20 dot 1510141240330 dot 2509 at laptop-mg dot saclay dot inria dot fr> <CAFiYyc3sS46khXFpZLetingTYuN5=2fu3N76+oErNShsRH3dvA at mail dot gmail dot com>
- Reply-to: gcc-patches at gcc dot gnu dot org
On Wed, 14 Oct 2015, Richard Biener wrote:
On Wed, Oct 14, 2015 at 12:45 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
On Wed, 14 Oct 2015, Richard Biener wrote:
+/* Fold (a * (1 << b)) into (a << b) */
+(simplify
+ (mult:c @0 (convert? (lshift integer_onep@1 @2)))
+ (if (! FLOAT_TYPE_P (type)
+ && tree_nop_conversion_p (type, TREE_TYPE (@2)))
+ (lshift @0 (convert @2))))
You don't need/want to convert @2 (fold-const doesn't convert, does it?),
and you don't need to check for tree_nop_conversion_p.
I think for long x and x * (long)(1u << b) you need to do because the
result for b == 33 would be different.
- that check should be with TREE_TYPE (@1)
of course
- 1u << 33 is undefined, isn't it?
Is it? I thought it were fine for unsigned.
Can't be, Intel thinks it is 2u while some other hardware thinks it is 0.
Not sure if we should exploit this
undefinedness here. Btw, if it were a truncating conversion then the
resulting shift could be invalid if @2 is too big (but not too big for the
wider shift).
Yes, that was my example below.
So either way I think we should only allow nop conversions
here (as fold-const.c did).
I agree that's the safest / easiest for now.
x * (int)(1ul << b), which for b=33 should yield 0, would give the undefined
x << b so some check does seem needed indeed.
--
Marc Glisse