On Fri, Sep 10, 2021 at 03:15:56PM +0200, Richard Biener wrote:
> On Fri, Sep 10, 2021 at 2:58 PM liuhongt <hongtao....@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
