Re: Target FUNCTION_{PRO,EPI}LOGUE question

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Thu, 28 Jun 2001, Neil Booth wrote:

> > I'm supposing that the integer representation - representing a signed
> > integer, with no specified type - is independent of C language rules for
> > unsigned arithmetic, overflow, interactions of different types, etc..  An
> > INTEGER_CST would then contain such an integer, together with type
> > information; and front ends would use the type, and general integer
> > functions (such a multiplying two unsigned integers modulo a given power
> > of 2), to implement the language-specific arithmetic rules.
> 
> OK.  But why not represent all of type + functions by just a vtable
> pointer?  It cuts out a lot of if statements, if nothing else.

Could you explain in more detail what you're proposing, for both the 
language-independent and the language-dependent parts of GCC?

> Presumably (cast + intwidth1) would decay to intwidth2 in a suitable
> way.  This would need implicit casts to be supplied, but I believe
> they are anyway.  If done properly, you'd only ever be operating on
> same-size ints.

The implicit casts would continue to be provided by the front ends.  
You'd need to make sure that same-size implied same representation -
including, say, that a constant 0 long long was represented in the same
way as a larger constant long long, when adding long longs (even if a
smaller representation might otherwise be prefered for a constant 0).

> I still don't see your point - the integer representation would be
> embedded in the INTEGER_CST, and so be garbage collected with it.

It would also be embedded in RTL.  It would also be embedded everywhere
else in the compiler that uses a HOST_WIDE_INT variable or an array of 2
of them to represent a target integer.  Everywhere that uses target
integers temporarily, without needing to construct a tree around them,
might need to do allocation rather than just declaring a variable.

-- 
Joseph S. Myers
jsm28@cam.ac.uk