This is the mail archive of the
mailing list for the GCC project.
Re: wide-int branch now up for public comment and review
- From: Mike Stump <mikestump at comcast dot net>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Richard Sandiford <rdsandiford at googlemail dot com>, Kenneth Zadeck <zadeck at naturalbridge dot com>, <rguenther at suse dot de>, gcc-patches <gcc-patches at gcc dot gnu dot org>, <r dot sandiford at uk dot ibm dot com>
- Date: Sun, 25 Aug 2013 14:38:36 -0700
- Subject: Re: wide-int branch now up for public comment and review
- References: <520A9DCC dot 6080609 at naturalbridge dot com> <87ppt4e9hg dot fsf at talisman dot default> <B2FB5C39-EAA7-48FF-A063-FC496FF10E03 at comcast dot net> <Pine dot LNX dot 4 dot 64 dot 1308252005090 dot 1471 at digraph dot polyomino dot org dot uk>
On Aug 25, 2013, at 1:11 PM, "Joseph S. Myers" <email@example.com> wrote:
> On Sun, 25 Aug 2013, Mike Stump wrote:
>> On Aug 23, 2013, at 8:02 AM, Richard Sandiford <firstname.lastname@example.org> wrote:
>>> We really need to get rid of the #include "tm.h" in wide-int.h.
>>> MAX_BITSIZE_MODE_ANY_INT should be the only partially-target-dependent
>>> thing in there. If that comes from tm.h then perhaps we should put it
>>> into a new header file instead.
>> BITS_PER_UNIT comes from there as well, and I'd need both. Grabbing the
>> #defines we generate is easy enough, but BITS_PER_UNIT would be more
>> annoying. No port in the tree makes use of it yet (other than 8). So,
>> do we just assume BITS_PER_UNIT is 8?
> Regarding avoiding tm.h dependence through BITS_PER_UNIT (without actually
> converting it from a target macro to a target hook), see my suggestions at
> <http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02617.html>. It would seem
> fairly reasonable, if in future other macros are converted to hooks and
> it's possible to build multiple back ends into a single compiler binary,
> to require that all such back ends share a value of BITS_PER_UNIT.
Ick. I don't see the beauty of this direction. If one wants to move in a, we can generate code for any target, fine, let's do that. If someone wants to make a target, just a dynamically loaded shared library, let's do that. There are all sorts of directions to move it, but the intermediate, let's design and implement a system, where for some targets it works, and for some targets it doesn't work, well, I think that is short sighted and we ought not target that.
Having a separate tm-blabla.h for some of the selections of the target is fine, but mandating that as the form for doing a target is, well, bad.
I'd love to see the entire hook and target selection mechanism brought up to 1990's level of sophistication, the 1970s are over. Sigh. Anyway, all this is well beyond the scope of the work at hand.
> As I've previously
> noted, many front-end uses of BITS_PER_UNIT really care about the C-level
> char and so should be TYPE_PRECISION (char_type_node). Generally, before
> thinking about how to get BITS_PER_UNIT somewhere, consider whether the
> code is actually correct to be using BITS_PER_UNIT at all - whether it's
> the RTL-level QImode that is really what's relevant to the code.
I think we got all the uses correct. Let us know if any are wrong.