http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #22 from Paulo J. Matos pa...@matos-sorge.com ---
After some thought, I am concluding this cannot actually be optimized and that
GCC 4.5.4 was better because it was taking advantage of an undefined behaviour
that doesn't exist.
The
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #23 from rguenther at suse dot de rguenther at suse dot de ---
On Wed, 12 Feb 2014, pa...@matos-sorge.com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #22 from Paulo J. Matos pa...@matos-sorge.com ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
pmatos at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #20 from Paulo J. Matos pa...@matos-sorge.com ---
OK, I was trying to make sense of all this and there are two things that stick
out.
One is when you say that due to C integer promotion rules make i =
(short)((int)i + 1). However GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #21 from rguenther at suse dot de rguenther at suse dot de ---
On Fri, 7 Feb 2014, pa...@matos-sorge.com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #20 from Paulo J. Matos pa...@matos-sorge.com ---
OK, I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #12 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Paulo J. Matos from comment #10)
(In reply to Paulo J. Matos from comment #8)
Made a mistake. With the attached test, the final gimple before expand for
the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #13 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to Richard Biener from comment #12)
Note that {1, +, 1}_1 is unsigned. The issue is that while i is short
i++ is really i = (short)((int) i + 1) and thus only the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #14 from Paulo J. Matos pa...@matos-sorge.com ---
Something like this which looks much simpler hits the same problem:
extern int arr[];
void
foo32 (int limit)
{
short i;
for (i = 0; (int)i limit; i++)
arr[i] += 1;
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #15 from rguenther at suse dot de rguenther at suse dot de ---
On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #14 from Paulo J. Matos pa...@matos-sorge.com ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #16 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to rguent...@suse.de from comment #15)
Exactly the same problem. C integral type promotion rules make
that i = (short)((int)i + 1) again. Note that (int)i + 1
does not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #17 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to rguent...@suse.de from comment #15)
On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #14 from Paulo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #18 from rguenther at suse dot de rguenther at suse dot de ---
On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #17 from Paulo J. Matos pa...@matos-sorge.com ---
(In
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #19 from rguenther at suse dot de rguenther at suse dot de ---
On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #16 from Paulo J. Matos pa...@matos-sorge.com ---
(In
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #7 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to Richard Biener from comment #5)
Apart from expand there is the redundant-extension-elimination, ree.c.
In expand we get the following gimple for the loop:
;; basic block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #8 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to Paulo J. Matos from comment #7)
(In reply to Richard Biener from comment #5)
Apart from expand there is the redundant-extension-elimination, ree.c.
In expand we get
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #9 from Paulo J. Matos pa...@matos-sorge.com ---
Created attachment 32044
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32044action=edit
Testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #10 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to Paulo J. Matos from comment #8)
Made a mistake. With the attached test, the final gimple before expand for
the loop basic block is:
;; basic block 5, loop depth 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #11 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to Paulo J. Matos from comment #10)
(In reply to Paulo J. Matos from comment #8)
Made a mistake. With the attached test, the final gimple before expand for
the loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #4 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to Richard Biener from comment #3)
Yes, I think that the IV choice merely shows that we miss to optimize the
extension - which would be somewhere in the RTL opt pipeline.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
Apart from expand there is the redundant-extension-elimination, ree.c.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #6 from Paulo J. Matos pa...@matos-sorge.com ---
humm, ree is no good because by then we missed already the generation of zero
overhead loops. Do you think this is something that could be added to expand?
22 matches
Mail list logo
