wide-int branch now up for public comment and review

[Joseph S. Myers]

On Sun, 25 Aug 2013, Mike Stump wrote:

> On Aug 23, 2013, at 8:02 AM, Richard Sandiford <rdsandiford@googlemail.com> 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.

BITS_PER_UNIT describes the number of bits in QImode - the RTL-level byte.  
I don't think wide-int should care about that at all.  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.

-- 
Joseph S. Myers
joseph@codesourcery.com