[Bug tree-optimization/18065] usual arithmetic conversion not applying correctly

["schlie at comcast dot net" <gcc-bugzilla@gcc.gnu.org>]

------- Additional Comments From schlie at comcast dot net  2004-10-21 01:04 -------
Subject: Re:  usual arithmetic conversion not
 applying correctly

Ok, a more basic observation/recommendation: the front end should not be
masking true operand types by promoting them prematurely, as it generates
very little value, while needlessly complicating the back-end's ability to
easily generate optimal code for non-integer width machines; as with
efficient access to the true source operand precision, and true operation
result precision requirements, the back end can then easily and directly
leverage the target's rtl machine description to generate fully conforming
precision code, with out the burden of having to back-out prematurely
applied type conversions (which seem wholly counterproductive).

(which of course is the point of being able to specify optimal QI, and in
many cases HI mode rtl instruction mappings, which have been made much less
efficient by the front-end's choice to needlessly prematurely type promote
operands prior to the literal requirement to do so.)

Thanks for hearing me out, and by the way this whole discussion began by
observing that GCC was not utilizing efficient rtl QI mode instruction
descriptions, resulting in the classification of the bug as a "missed
optimization" bug, as opposed to an "incorrect code" bug, with the
explanation that although the source and destination operands specified
in C could be implemented as specified in the rtl instruction mapping
specification and be fully conforming, it wasn't recognized because the
back-end didn't find the "optimization" because the front-end needlessly
prematurely type converted all operands passed to the back-end.

And for what little it may be worth, for good or bad, the factual reality
is that there are 100's of times more small processors programmed and
deployed in products than there are 32+ bit processors, therefore it would
be nice if GCC didn't needless restrict itself to being most optimally
applicable to larger machines at the expense of smaller machines (as there
far more commercial 8 and 16 bit processors available from companies
interested in support than their are 32-64 bit processor companies, and
likely to remain that way, so it's not likely good business to bite the
hand that may feed you).

-paul-


> From: jsm at polyomino dot org dot uk <gcc-bugzilla@gcc.gnu.org>
> Reply-To: <gcc-bugzilla@gcc.gnu.org>
> Date: 20 Oct 2004 23:03:15 -0000
> To: <schlie@comcast.net>
> Subject: [Bug tree-optimization/18065] usual arithmetic conversion not
> applying correctly
> 
> 
> ------- Additional Comments From jsm at polyomino dot org dot uk  2004-10-20
> 23:03 -------
> Subject:  Re: C integer promotion semantics /
>  front end problems.
> 
> I presume you sent your message directly to me by mistake, so am sending
> the reply back to the bug database so it can benefit more than one person.
> Technical messages about public GCC versions should, absent any more
> specific support arrangements in a particular case, go to the mailing
> lists, not individuals; questions are answered in public GCC development
> for the benefit of the public.
> 
> On Wed, 20 Oct 2004, Paul Schlie wrote:
> 
>> Sorry to do this to you again, but where do you see in the standard the
>> requirement to promote, or license to needlessly promote all operands
>> to int?
> 
> C99 subclause 6.3.1.1 paragraph 2.  signed char has rank less than that of
> int, so it *must* be promoted to int.  What happens afterwards is nothing
> to do with the front end.  The front end does *too many* optimisations; it
> should purely generate GIMPLE representing the standard meaning of the
> code and leave it to the later stages to tell that such conversions - or
> indeed conversions between int and long where they are the same size - can
> be optimised away in some cases.
> 
> -- 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065
> 
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065