On September 10, 2021 3:30:10 PM GMT+02:00, Segher Boessenkool
<seg...@kernel.crashing.org> wrote:
>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.
OK, so there's a mode class comparison missing here which should be a better
fix than calling validate_subreg?
Richard.
>
>Segher
