This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][RFC] Bit CCP and pointer alignment propagation


On Fri, 30 Jul 2010, Paolo Bonzini wrote:

> On 07/30/2010 03:15 PM, Richard Guenther wrote:
> > I think we can have negative shift counts (at least the constant folding
> > code suggests so), this is why I have the code as-is.
> 
> No, that seems very weird.  Sure expand does not handle it, and the
> implementation-defined section of the manual does not mention it.  I'm more
> inclined to consider it a historical wart, given this comment:
> 
>   /* Previously detected shift-counts computed by NEGATE_EXPR
>      and shifted in the other direction; but that does not work
>      on all machines.  */
> 
> dating back to the beginning of the GCC repo.  I wonder what the attached
> patch would do.

Maybe - at least with 2 << -1 we only warn:

t.c:3: warning: left shift count is negative

and happily continue, doing a constant right shift.  With -1 put
into a temporary we get sall with a negative shift at -O0 (and
zero as a result) and one as result when optimizing.

> BTW the SHIFT_COUNT_TRUNCATED handling is not needed because you get it from
> lshift_double.  However, this opens another small can of worms. lshift_double
> does
> 
>   if (SHIFT_COUNT_TRUNCATED)
>     count %= prec;
> 
> which makes bit-level analysis totally wrong for non-power-of-two precisions,
> including IIRC bitfields bigger than sizeof(int).  I think the shifting
> functions are wrong however, and should round prec up to the next power of two
> before applying the truncation.

Ick.  Indeed ...

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]