This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFA:] Fix gcc.c-torture/execute/20020720-1.x and further analysis
- From: Roger Sayle <roger at eyesopen dot com>
- To: Hans-Peter Nilsson <hp at bitrange dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 31 Aug 2002 10:22:17 -0600 (MDT)
- Subject: Re: [RFA:] Fix gcc.c-torture/execute/20020720-1.x and further analysis
Hi Hans-Peter,
> Request for approval since this also changes the reason-for-
> failure comment, not just adding MMIX to the bunch of XFAIL
> targets.
As you know I'm for this patch. However I'd like to say a few words
in my defense, by way of an apology.
> I do think the abs-optimization is misplaced since it depends on
> the machine description and GCC to not split up the (abs(x) <
> 0.0) expression into too many parts. This optimization (if done
> at the RTL level at all) would be better placed in ifcvt.c;
> that'd supposedly let the optimization happen for more targets.
Alas, the motivation for this optimization is to catch the poor
code generated by dividing a complex number by a real. The problem
here is that the 0.0 isn't visible to the compiler until after
GCSE/CSE, so to fix this case the transformation must be applied
at the RTL level. I'm must admit that I haven't considered placing
this transformation in ifcvt.c.
> But I really dislike the wording in that comment: the machine
> description is precise (in these parts, at least), it's *not*
> obfuscated. To the contrary, tweaking the md to appease the
> code for the abs-optimization would be to obfuscate it.
The wording of the original comment was that "the machine descriptions
obfuscate the 'abs(x) < 0.0' comparison". I wasn't claiming that the
.md files were or weren't "obfuscated", but that the RTL they create
is harder for GCC to comprehend. I also appreciate that it may be
significantly harder to write MD patterns that GCC can manipulate.
> :-) Oh well, not a native speaker and all that.
:>
As I've mentioned in earlier messages, I've been working on a fix
that'll optimize comparisons that are split into four instructions,
such as on powerpc and mmix. At present, the backend only handles
architectures that split comparisons into two instructions (such as
alpha), or into three insns (such as x86).
Any machine description that splits comparisons into five or more
instructions (no matter how clearly written) will always fail this
test case.
I've been delayed submitting the "four instruction comparison" patch
because the powerpc toolchain won't build from Linux, and I've been
delayed in fixing this subreg with negative offest problem because
the mainline won't bootstrap with --enable-checking, which has been
delayed by ....
To conclude, I prefer the new wording. The original could have/has
been misinterpreted as acusing the machine descriptions as being
poorly written, rather than accurately describing the processor.
The issue, like the CISC vs. RISC debate, is that some architecture's
instruction sequences make the intention of the code clearer. This
is what mid-level RTL hopes to address.
Sorry for any confusion. No slight was intended.
Roger
--