On Thu, 30 Aug 2018, Jakub Jelinek wrote:
> On Thu, Aug 30, 2018 at 09:57:48AM +0200, Richard Biener wrote:
> > > > Ugh. I wonder if we should add a
> > > >
> > > > rtx gen_int_mode (poly_uint64 c, machine_mode mode)
> > > >
> > > > and assert that the topmost bit is not set if GET_MODE_PRECISI
On Thu, Aug 30, 2018 at 09:57:48AM +0200, Richard Biener wrote:
> > > Ugh. I wonder if we should add a
> > >
> > > rtx gen_int_mode (poly_uint64 c, machine_mode mode)
> > >
> > > and assert that the topmost bit is not set if GET_MODE_PRECISION (mode) >
> > > 64?
> > >
> > > But I guess passing
On Thu, 30 Aug 2018, Jakub Jelinek wrote:
> On Thu, Aug 30, 2018 at 09:31:01AM +0200, Richard Biener wrote:
> > > The following testcase is miscompiled, because expand_mult_const adds an
> > > incorrect REG_EQUAL note to a temporary pseudo. In the testcase, we
> > > do an unsigned __int128 multip
On Thu, Aug 30, 2018 at 09:31:01AM +0200, Richard Biener wrote:
> > The following testcase is miscompiled, because expand_mult_const adds an
> > incorrect REG_EQUAL note to a temporary pseudo. In the testcase, we
> > do an unsigned __int128 multiplication of a variable by
> > 0x7fff, w
On Thu, 30 Aug 2018, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled, because expand_mult_const adds an
> incorrect REG_EQUAL note to a temporary pseudo. In the testcase, we
> do an unsigned __int128 multiplication of a variable by
> 0x7fff, which is determined t
Hi!
The following testcase is miscompiled, because expand_mult_const adds an
incorrect REG_EQUAL note to a temporary pseudo. In the testcase, we
do an unsigned __int128 multiplication of a variable by
0x7fff, which is determined to be best performed as
shift left by 63 (multiplication
