On Sat, Jul 11, 2020 at 8:29 PM Roger Sayle <ro...@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 <ro...@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 >
