Re: [PATCH 2/2] validate_subreg before call gen_lowpart to avoid ICE.

[Segher Boessenkool <segher@kernel.crashing.org>]

On Fri, Sep 10, 2021 at 03:15:56PM +0200, Richard Biener wrote:
> On Fri, Sep 10, 2021 at 2:58 PM liuhongt <hongtao.liu@intel.com> wrote:
> >        if (REG_P (target)
> > -         && TRULY_NOOP_TRUNCATION_MODES_P (GET_MODE (target), ext_mode))
> 
> ^^^
> 
> I wonder if herein lies the problem in that the HFmode "truncation" from SImode
> is considered noop?  Note the underlying target hook only looks at the mode
> precision and thus receives 16 and 32, and thus maybe that
> TRULY_NOOP_TRUNCATION_MODES_P query only makes sense for
> integer modes?  Though the documentation of the hook only talks about
> "conversion" of "values" ...

@deftypefn {Target Hook} bool TARGET_TRULY_NOOP_TRUNCATION (poly_uint64 @var{outprec}, poly_uint64 @var{inprec})
This hook returns true if it is safe to ``convert'' a value of
@var{inprec} bits to one of @var{outprec} bits (where @var{outprec} is
smaller than @var{inprec}) by merely operating on it as if it had only
@var{outprec} bits.  The default returns true unconditionally, which
is correct for most machines.  When @code{TARGET_TRULY_NOOP_TRUNCATION}
returns false, the machine description should provide a @code{trunc}
optab to specify the RTL that performs the required truncation.


@cindex @code{trunc@var{m}@var{n}2} instruction pattern
@item @samp{trunc@var{m}@var{n}2}
Truncate operand 1 (valid for mode @var{m}) to mode @var{n} and
store in operand 0 (which has mode @var{n}).  Both modes must be fixed
point or both floating point.


TRULY_NOOP_TRUNCATION does not make sense to ask if changing mode class.


Segher