how to check if target supports andnot instruction ?

2016-10-12 Thread Prathamesh Kulkarni
Hi, I was having a look at PR71636 and added the following pattern to match.pd: x & ((1U << b) - 1) -> x & ~(~0U << b) However the transform is useful only if the target supports "andnot" instruction. As pointed out by Marc in PR for -march=core2, lhs generates worse code than rhs, so we shouldn't

Re: how to check if target supports andnot instruction ?

2016-10-12 Thread Prathamesh Kulkarni
On 12 October 2016 at 13:09, Prathamesh Kulkarni wrote: > Hi, > I was having a look at PR71636 and added the following pattern to match.pd: > x & ((1U << b) - 1) -> x & ~(~0U << b) > However the transform is useful only if the target supports "andnot" > instruction. > As pointed out by Marc in PR

Re: how to check if target supports andnot instruction ?

2016-10-12 Thread Richard Biener
On Wed, 12 Oct 2016, Prathamesh Kulkarni wrote: > Hi, > I was having a look at PR71636 and added the following pattern to match.pd: > x & ((1U << b) - 1) -> x & ~(~0U << b) > However the transform is useful only if the target supports "andnot" > instruction. > As pointed out by Marc in PR for -mar

Re: how to check if target supports andnot instruction ?

2016-10-12 Thread Marc Glisse
On Wed, 12 Oct 2016, Prathamesh Kulkarni wrote: I was having a look at PR71636 and added the following pattern to match.pd: x & ((1U << b) - 1) -> x & ~(~0U << b) However the transform is useful only if the target supports "andnot" instruction. rth was selling the transformation as a canonical

Re: how to check if target supports andnot instruction ?

2016-10-12 Thread Richard Biener
On Wed, 12 Oct 2016, Marc Glisse wrote: > On Wed, 12 Oct 2016, Prathamesh Kulkarni wrote: > > > I was having a look at PR71636 and added the following pattern to match.pd: > > x & ((1U << b) - 1) -> x & ~(~0U << b) > > However the transform is useful only if the target supports "andnot" > > instr

Potential bug with wide_int_storage::set_len

2016-10-12 Thread Andre Vieira (lists)
Hello, During the development of a patch I encountered some strange behavior and decided to investigate. The result of which is I think I found a bug with 'wide_int_storage::set_len' in gcc/wide-int.h. The function reads: inline void wide_int_storage::set_len (unsigned int l, bool is_sign_extende

Potential bug with wide_int_storage::set_len

2016-10-12 Thread Andre Vieira (lists)
Hello, During the development of a patch I encountered some strange behavior and decided to investigate. The result of which is I think I found a bug with 'wide_int_storage::set_len' in gcc/wide-int.h. The function reads: inline void wide_int_storage::set_len (unsigned int l, bool is_sign_extende

Re: Potential bug with wide_int_storage::set_len

2016-10-12 Thread Jakub Jelinek
On Wed, Oct 12, 2016 at 05:02:46PM +0100, Andre Vieira (lists) wrote: > Say you are running it on a 64-bit host: > #define HOST_BITS_PER_WIDE_INT 64 > > and you call 'result.set_len (1, false);' > > Then this will sign extend the first element of val, to > 0x, and I don't think th

Re: Potential bug with wide_int_storage::set_len

2016-10-12 Thread Jakub Jelinek
On Wed, Oct 12, 2016 at 06:45:39PM +0200, Jakub Jelinek wrote: > On Wed, Oct 12, 2016 at 05:02:46PM +0100, Andre Vieira (lists) wrote: > > Say you are running it on a 64-bit host: > > #define HOST_BITS_PER_WIDE_INT 64 > > > > and you call 'result.set_len (1, false);' > > > > Then this will sign e

Re: Potential bug with wide_int_storage::set_len

2016-10-12 Thread Eric Botcazou
> During the development of a patch I encountered some strange behavior > and decided to investigate. The result of which is I think I found a bug > with 'wide_int_storage::set_len' in gcc/wide-int.h. > > The function reads: > inline void > wide_int_storage::set_len (unsigned int l, bool is_sign_e