This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: wide-int branch now up for public comment and review

On Aug 25, 2013, at 1:11 PM, "Joseph S. Myers" <> wrote:
> On Sun, 25 Aug 2013, Mike Stump wrote:
>> On Aug 23, 2013, at 8:02 AM, Richard Sandiford <> 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 
> <>.  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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]