middle-end: Remove truly_noop_truncation check from convert.c

This patch eliminates a check of targetm.truly_noop_truncation from
the early middle-end, where the gimple/generic being generated by
GCC's front-ends is being inappropriately influenced by the target's
TRULY_NOOP_TRUNCATION.  The (recent) intention of TRULY_NOOP_TRUNCATION
is to indicate that a backend requires explicit truncation instructions
rather than using SUBREGs to perform truncations.  A long standing
(and probably unintentional) side-effect has been that this setting
also controls whether the middle-end narrows integer operations at
the tree-level.  Understandably, GCC and its testsuite assume that
GIMPLE and GENERIC behave consistently across platforms, and alas
defining TRULY_NOOP_TRUNCATION away from the default triggers several
regressions (including gcc.dg/fold-rotate-1.c).

Hopefully, I can appeal to a design philosophy argument that the
early middle-end (tree-ssa) passes should be as machine independent
as possible, and target settings influence the late middle-end (RTL)
passes.  Most of the backend hooks were eliminated from "fold" and
the tree code with GCC 4.x, but perhaps TRULY_NOOP_TRUNCATION appears
to have survived, probably because it is so rarely used.  It's only
defined by three (current) backends: gcn, mips and tilegx.  Everywhere
else TRULY_NOOP_TRUNCATION is unconditionally true, so that
convert_to_integer_1 always calls do_narrow.

This check of TRULY_NOOP_TRUNCATION (in convert_to_integer) dates back
to (before) gcc 0.9 in 1987.  Mysteriously, at that point in time, all
targets defined TRULY_NOOP_TRUNCATION to 1, so perhaps only Richard
Stallman remembers why this code was ever added to the compiler.
Even if truncations require explicit instructions, that shouldn't
prevent the compiler from generating them (or using narrow integer
operations).

The following patch has been tested on x86_64-pc-linux-gnu with
no regressions (where of course you wouldn't expect any changes),
and on a x86_64-pc-linux-gnu that defines TRULY_NOOP_TRUNCATION
to false, where it cures 17 of the regressions that are introduced.
It also fixes all of the regressions introduced by defining
TRULY_NOOP_TRUNCATION to false on nvptx-none.  I had hoped to
also test on a MIPS target, but after over 10 days of bootstrap builds
on the GCC compile farm, gcc23.fsffrance.org has started experiencing
hardware issues (overheating?), so it may be a while before I can
fully confirm this change causes no problems (and potentially fixes
a few) on MIPS.

Ok for mainline?

2020-07-11  Roger Sayle  <roger@nextmovesoftware.com>

gcc/ChangeLog
	* convert.c (convert_to_integer_1): Narrow integer operations
	even on targets that require explicit truncation instructions.

Thanks in advance,
Roger
--
Roger Sayle
NextMove Software
Cambridge, UK

On Sat, Jul 11, 2020 at 8:29 PM Roger Sayle <roger@nextmovesoftware.com> wrote:
>
>
> This patch eliminates a check of targetm.truly_noop_truncation from
> the early middle-end, where the gimple/generic being generated by
> GCC's front-ends is being inappropriately influenced by the target's
> TRULY_NOOP_TRUNCATION.  The (recent) intention of TRULY_NOOP_TRUNCATION
> is to indicate that a backend requires explicit truncation instructions
> rather than using SUBREGs to perform truncations.  A long standing
> (and probably unintentional) side-effect has been that this setting
> also controls whether the middle-end narrows integer operations at
> the tree-level.  Understandably, GCC and its testsuite assume that
> GIMPLE and GENERIC behave consistently across platforms, and alas
> defining TRULY_NOOP_TRUNCATION away from the default triggers several
> regressions (including gcc.dg/fold-rotate-1.c).
>
> Hopefully, I can appeal to a design philosophy argument that the
> early middle-end (tree-ssa) passes should be as machine independent
> as possible, and target settings influence the late middle-end (RTL)
> passes.  Most of the backend hooks were eliminated from "fold" and
> the tree code with GCC 4.x, but perhaps TRULY_NOOP_TRUNCATION appears
> to have survived, probably because it is so rarely used.  It's only
> defined by three (current) backends: gcn, mips and tilegx.  Everywhere
> else TRULY_NOOP_TRUNCATION is unconditionally true, so that
> convert_to_integer_1 always calls do_narrow.
>
> This check of TRULY_NOOP_TRUNCATION (in convert_to_integer) dates back
> to (before) gcc 0.9 in 1987.  Mysteriously, at that point in time, all
> targets defined TRULY_NOOP_TRUNCATION to 1, so perhaps only Richard
> Stallman remembers why this code was ever added to the compiler.
> Even if truncations require explicit instructions, that shouldn't
> prevent the compiler from generating them (or using narrow integer
> operations).
>
> The following patch has been tested on x86_64-pc-linux-gnu with
> no regressions (where of course you wouldn't expect any changes),
> and on a x86_64-pc-linux-gnu that defines TRULY_NOOP_TRUNCATION
> to false, where it cures 17 of the regressions that are introduced.
> It also fixes all of the regressions introduced by defining
> TRULY_NOOP_TRUNCATION to false on nvptx-none.  I had hoped to
> also test on a MIPS target, but after over 10 days of bootstrap builds
> on the GCC compile farm, gcc23.fsffrance.org has started experiencing
> hardware issues (overheating?), so it may be a while before I can
> fully confirm this change causes no problems (and potentially fixes
> a few) on MIPS.
>
> Ok for mainline?

OK.  The other big early target dependence is of course
LOGICAL_OP_NON_SHORT_CIRCUIT ... (aka BRANCH_COST).

Thanks,
Richard.

> 2020-07-11  Roger Sayle  <roger@nextmovesoftware.com>
>
> gcc/ChangeLog
>         * convert.c (convert_to_integer_1): Narrow integer operations
>         even on targets that require explicit truncation instructions.
>
> Thanks in advance,
> Roger
> --
> Roger Sayle
> NextMove Software
> Cambridge, UK
>