Re: [PATCH] Introduce [sg]et_nonzero_bits

2013-10-30 Thread Richard Biener
On Tue, 29 Oct 2013, Jakub Jelinek wrote: On Tue, Oct 29, 2013 at 12:55:04PM +0100, Richard Biener wrote: Surely you can't rely on CCP and VRP compute exactly the same nonzero_bits. As you don't record/compute zero_bits you can't tell whether a not set bit in nonzer_bits is don't know or

Re: [PATCH] Introduce [sg]et_nonzero_bits

2013-10-30 Thread Richard Biener
On Tue, 29 Oct 2013, Jakub Jelinek wrote: Hi! On Tue, Oct 29, 2013 at 04:29:56PM +0100, Jakub Jelinek wrote: Surely you can't rely on CCP and VRP compute exactly the same nonzero_bits. As you don't record/compute zero_bits you can't tell whether a not set bit in nonzer_bits is don't

Re: [PATCH] Introduce [sg]et_nonzero_bits

2013-10-29 Thread Richard Biener
On Fri, 25 Oct 2013, Jakub Jelinek wrote: Hi! tree-ssa-ccp.c already computes which bits are known to be zero, but we preserve that info only for pointers and not for integers. This patch changes SSA_NAME_RANGE_INFO, so we preserve that info even for integers. The bitmask is also computed

Re: [PATCH] Introduce [sg]et_nonzero_bits

2013-10-29 Thread Jakub Jelinek
On Tue, Oct 29, 2013 at 12:55:04PM +0100, Richard Biener wrote: Surely you can't rely on CCP and VRP compute exactly the same nonzero_bits. As you don't record/compute zero_bits you can't tell whether a not set bit in nonzer_bits is don't know or if it is zero. And you cannot do an assert

Re: [PATCH] Introduce [sg]et_nonzero_bits

2013-10-29 Thread Jakub Jelinek
Hi! On Tue, Oct 29, 2013 at 04:29:56PM +0100, Jakub Jelinek wrote: Surely you can't rely on CCP and VRP compute exactly the same nonzero_bits. As you don't record/compute zero_bits you can't tell whether a not set bit in nonzer_bits is don't know or if it is zero. And you cannot do an

[PATCH] Introduce [sg]et_nonzero_bits

2013-10-25 Thread Jakub Jelinek
Hi! tree-ssa-ccp.c already computes which bits are known to be zero, but we preserve that info only for pointers and not for integers. This patch changes SSA_NAME_RANGE_INFO, so we preserve that info even for integers. The bitmask is also computed from range info. There are no users of this