On 1/3/24 16:39, Richard Sandiford wrote:
YunQiang Su writes:
On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms,
if 31 or above bits is polluted by an bitops, we will need an
truncate. Let's emit one, and mark let's use the same hardreg
as in and out, the RTL may like:
(i
YunQiang Su writes:
> On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms,
> if 31 or above bits is polluted by an bitops, we will need an
> truncate. Let's emit one, and mark let's use the same hardreg
> as in and out, the RTL may like:
>
> (insn 21 20 24 2 (set (subreg/s/u:SI (r
On 12/24/23 05:24, Roger Sayle wrote:
What's exceedingly weird is T_N_T_M_P (DImode, SImode) isn't
actually a truncation! The output precision is first, the input
precision is second. The docs explicitly state the output precision
should be smaller than the input precision (which makes sen
On 12/24/23 01:11, YunQiang Su wrote:
Yes. I also guess so. Any new idea?
Well, I see multiple intertwined issues and I think MIPS has largely
mucked this up.
At a high level DI -> SI truncation is not a nop on MIPS64. We must
explicitly sign extend the value from SI->DI to preserve the in
> > > What's exceedingly weird is T_N_T_M_P (DImode, SImode) isn't
> > > actually a truncation! The output precision is first, the input
> > > precision is second. The docs explicitly state the output precision
> > > should be smaller than the input precision (which makes sense for
> > > trunc
On Sun, Dec 24, 2023, 01:18 YunQiang Su wrote:
> Roger Sayle 于2023年12月24日周日 16:51写道：
> >
> >
> > > What's exceedingly weird is T_N_T_M_P (DImode, SImode) isn't actually a
> > > truncation! The output precision is first, the input precision is
> second. The docs
> > > explicitly state the outpu
Roger Sayle 于2023年12月24日周日 16:51写道：
>
>
> > What's exceedingly weird is T_N_T_M_P (DImode, SImode) isn't actually a
> > truncation! The output precision is first, the input precision is second.
> > The docs
> > explicitly state the output precision should be smaller than the input
> > precisio
> What's exceedingly weird is T_N_T_M_P (DImode, SImode) isn't actually a
> truncation! The output precision is first, the input precision is second.
> The docs
> explicitly state the output precision should be smaller than the input
> precision
> (which makes sense for truncation).
>
> That
Roger Sayle 于2023年12月24日周日 08:49写道：
>
>
> Hi YunQiang (and Jeff),
>
> > MIPS claims TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true
> > based on that the hard register is always sign-extended, but here
> > the hard register is polluted by zero_extract.
>
> I suspect that the bug here is th
> > Yes. I also guess so. Any new idea?
> Well, I see multiple intertwined issues and I think MIPS has largely
> mucked this up.
>
> At a high level DI -> SI truncation is not a nop on MIPS64. We must
> explicitly sign extend the value from SI->DI to preserve the invariant
> that SI mode objects
On 12/23/23 17:49, Roger Sayle wrote:
Hi YunQiang (and Jeff),
MIPS claims TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) ==
true based on that the hard register is always sign-extended, but
here the hard register is polluted by zero_extract.
I suspect that the bug here is that the MIPS b
On 12/23/23 15:46, YunQiang Su wrote:
Jeff Law 于2023年12月24日周日 00:51写道：
On 12/23/23 01:58, YunQiang Su wrote:
On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms,
if 31 or above bits is polluted by an bitops, we will need an
truncate. Let's emit one, and mark let's use th
> Sent: 24 December 2023 00:50
> To: 'gcc-patches@gcc.gnu.org' ; 'YunQiang Su'
>
> Cc: 'Jeff Law'
> Subject: Re: [PATCH v3] EXPR: Emit an truncate if 31+ bits polluted for
SImode
>
>
> Hi YunQiang (and Jeff),
>
> > MIPS claims T
Hi YunQiang (and Jeff),
> MIPS claims TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true
> based on that the hard register is always sign-extended, but here
> the hard register is polluted by zero_extract.
I suspect that the bug here is that the MIPS backend shouldn't be returning
true for
Jeff Law 于2023年12月24日周日 00:51写道：
>
>
>
> On 12/23/23 01:58, YunQiang Su wrote:
> > On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms,
> > if 31 or above bits is polluted by an bitops, we will need an
> > truncate. Let's emit one, and mark let's use the same hardreg
> > as in and
On 12/23/23 01:58, YunQiang Su wrote:
On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms,
if 31 or above bits is polluted by an bitops, we will need an
truncate. Let's emit one, and mark let's use the same hardreg
as in and out, the RTL may like:
(insn 21 20 24 2 (set (subre
On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms,
if 31 or above bits is polluted by an bitops, we will need an
truncate. Let's emit one, and mark let's use the same hardreg
as in and out, the RTL may like:
(insn 21 20 24 2 (set (subreg/s/u:SI (reg/v:DI 200 [ val ]) 0)
17 matches
Mail list logo
