public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/67607] New: Failure to perform constant folding through type conversion
@ 2015-09-17 7:46 miyuki at gcc dot gnu.org
2015-09-17 8:15 ` [Bug tree-optimization/67607] " glisse at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: miyuki at gcc dot gnu.org @ 2015-09-17 7:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67607
Bug ID: 67607
Summary: Failure to perform constant folding through type
conversion
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: miyuki at gcc dot gnu.org
Target Milestone: ---
This code is taken from PR67606:
$ cat pr67606.c
int f(int a[], int length)
{
int count=0;
for (int i = 0 ; i < length ; i++)
if (a[i] > 5)
count++;
return count;
}
$ g++ -S -O3 -fno-tree-vectorize pr67606.c -fverbose-asm -fdump-tree-optimized
We get:
<bb 3>:
ivtmp.6_1 = (unsigned long) a_7(D);
_19 = (unsigned int) length_4(D);
_18 = _19 + 4294967295;
_21 = (sizetype) _18;
_22 = _21 + 1;
_23 = _22 * 4;
_24 = a_7(D) + _23;
_25 = (unsigned long) _24;
And this leads to generating some redundant code:
leal -1(%rsi), %eax #, tmp114
leaq 4(%rdi,%rax,4), %rcx #, tmp111
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug tree-optimization/67607] Failure to perform constant folding through type conversion
2015-09-17 7:46 [Bug tree-optimization/67607] New: Failure to perform constant folding through type conversion miyuki at gcc dot gnu.org
@ 2015-09-17 8:15 ` glisse at gcc dot gnu.org
2015-09-17 8:21 ` rguenth at gcc dot gnu.org
2015-09-21 11:39 ` glisse at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: glisse at gcc dot gnu.org @ 2015-09-17 8:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67607
--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
In general, for unsigned x, 1+(unsigned long)(x-1) can be simplified to x only
if we know that x!=0, so we would need VRP information.
Maybe this could be handled as part of the type-promotion work. VRP could tell
that _21+1 can be computed in type unsigned int, and swap the operation and the
conversion. Or it could tell that _19-1 can be computed in type unsigned long,
it doesn't matter much which one it picks. The simplification -1+1 would then
be trivial.
Last idea would be to try and avoid generating so many +1 and -1 in the first
place.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug tree-optimization/67607] Failure to perform constant folding through type conversion
2015-09-17 7:46 [Bug tree-optimization/67607] New: Failure to perform constant folding through type conversion miyuki at gcc dot gnu.org
2015-09-17 8:15 ` [Bug tree-optimization/67607] " glisse at gcc dot gnu.org
@ 2015-09-17 8:21 ` rguenth at gcc dot gnu.org
2015-09-21 11:39 ` glisse at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-09-17 8:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67607
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-09-17
CC| |rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
so this is
((unsigned long)((unsigned int) length_4(D) - 1U) + 1)
you can't optimize this to (unsigned long) length_4(D) as for
length_4 == 0 the result is 0x100000000.
So what's the missed constant folding? Ah, so the above is guarded with
if (length_4(D) > 0)
which means we fail to optimize this to (unsigned long)length_4(D) because
we don't consider this transform might be valid when taking into account
range-info.
# RANGE [1, 2147483647] NONZERO 2147483647
_19 = (unsigned int) length_4(D);
# RANGE [0, 2147483646] NONZERO 2147483647
_18 = _19 + 4294967295;
# RANGE [0, 2147483646] NONZERO 2147483647
_21 = (sizetype) _18;
# RANGE [1, 2147483647] NONZERO 2147483647
_22 = _21 + 1;
so here VRP could for example have promoted _19 and _18 to sizetype. Or
it could handle the arithmetic simplification itself. We'd like to handle
(T)(X +- CST1) +- CST1
generally here (both widening/shortening casts).
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug tree-optimization/67607] Failure to perform constant folding through type conversion
2015-09-17 7:46 [Bug tree-optimization/67607] New: Failure to perform constant folding through type conversion miyuki at gcc dot gnu.org
2015-09-17 8:15 ` [Bug tree-optimization/67607] " glisse at gcc dot gnu.org
2015-09-17 8:21 ` rguenth at gcc dot gnu.org
@ 2015-09-21 11:39 ` glisse at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: glisse at gcc dot gnu.org @ 2015-09-21 11:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67607
--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> ---
Created attachment 36362
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36362&action=edit
shortening
The shortening case seems much easier and does not require VRP information.
Calling get_range_info from match.pd is not done now (not sure if it would be a
good idea or not), so the widening case may have to be written separately in
VRP.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-09-21 11:39 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-17 7:46 [Bug tree-optimization/67607] New: Failure to perform constant folding through type conversion miyuki at gcc dot gnu.org
2015-09-17 8:15 ` [Bug tree-optimization/67607] " glisse at gcc dot gnu.org
2015-09-17 8:21 ` rguenth at gcc dot gnu.org
2015-09-21 11:39 ` glisse at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).