On 05/09/14 19:50, Richard Biener wrote:
> Well - the best way would be to expose the target specifics to GIMPLE
> at some point in the optimization pipeline. My guess would be that it's
> appropriate after loop optimizations (but maybe before induction variable
> optimization).
>
> That is, have a pass that applies register promotion to all SSA names
> in the function, inserting appropriate truncations and extensions. That
> way you'd never see (set (subreg...) on RTL. The VRP and DOM
> passes running after that pass would then be able to aggressively
> optimize redundant truncations and extensions.
>
> Effects on debug information are to be considered. You can change
> the type of SSA names in-place but you don't want to do that for
> user DECLs (and we can't have the SSA name type and its DECL
> type differ - and not sure if we might want to lift that restriction).
Thanks. I will try to implement this.
I still would like to keep the VRP based approach as there are some
cases that I think can only be done with range info. For example:
short foo(unsigned char c)
{
c = c & (unsigned char)0x0F;
if( c > 7 )
return((short)(c - 5));
else
return(( short )c);
}
So, how about adding and setting the overflow/wrap around flag to
range_info. We now set static_flag for VR_RANG/VR_ANTI_RANGE. If we go
back to the max + 1, min - 1 for VR_ANTI_RANGE, we can use this
static_flag to encode overflow/wrap around. Will that be something
acceptable?
Thanks again,
Kugan
