http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59999

--- 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=59999
> 
> --- 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 is doing i = (short) ((unsigned short) 
> i + 1). Am I missing something that allows this or makes the addition in 
> int equivalent to the addition in unsigned short?

This is a valid shortening optimization GCC performs.

> Secondly we still have a dangling sign_extend later on that we could 
> possibly optimize. I find it hard to understand if this can be done 
> properly in expand or if a small pass like ree but before zero overhead 
> loop generation is better. What do you think?

That entirely depends on where the extension is generated and what
information is present there ... if it can be avoided at expand
time then that's surely the best thing to do.  Maybe it can even
be avoided on the GIMPLE level.

Reply via email to