http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
pmatos at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #23 from 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 ---
> After some thought, I am concluding this canno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #22 from Paulo J. Matos ---
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 thought process is as fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #21 from 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 ---
> OK, I was trying to make sense of all this and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #20 from Paulo J. Matos ---
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 is doing i = (short) (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #19 from 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 ---
> (In reply to rguent...@suse.de from comment #15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #18 from 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 ---
> (In reply to rguent...@suse.de from comment #15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #17 from Paulo J. Matos ---
(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 J. Matos ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #16 from Paulo J. Matos ---
(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 overflow, (short) ((i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #15 from 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 ---
> Something like this which looks much simpler hi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #14 from Paulo J. Matos ---
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 #13 from Paulo J. Matos ---
(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 operation in
> type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #12 from Richard Biener ---
(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 basic block is:
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #11 from Paulo J. Matos ---
(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 basic block is:
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #10 from Paulo J. Matos ---
(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
> ;;pred:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #9 from Paulo J. Matos ---
Created attachment 32044
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32044&action=edit
Testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #8 from Paulo J. Matos ---
(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 the following gimpl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #7 from Paulo J. Matos ---
(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 4, loop depth 0
;;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #6 from Paulo J. Matos ---
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?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #5 from Richard Biener ---
Apart from expand there is the redundant-extension-elimination, ree.c.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #4 from Paulo J. Matos ---
(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.
Makes sense. My first
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Component|t
22 matches
Mail list logo
