This is the mail archive of the gcc@gcc.gnu.org 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]

Re: bounded pointers in RTL


Jeffrey A Law <law@cygnus.com> writes:

>   > I have been considering the possibility of reimplementing BPs without
>   > use of new modes, but it looks painful.  There are many places where
>   > only the machine mode communicates the size of a data object.
> Yup.  But it is also the case that every pass of the compiler is probably
> going to have to know something about the new modes.  Similarly for all
> the backends that define FUNCTION_ARG.

I reviewed my 2.7.2 diffs and found that I made no changes to
FUNCTION_ARG for any target.  I had BPs working for i386 and i960, and
for the latter, being passed in registers.  I also notice that DCmode
and SCmode are mentioned in target config files for only i370, i386,
m88k, sh, spur, tahoe, i960 and sparc.  Only sparc considers complex
modes for FUNCTION_ARG.  The rest only consider complex modes for
HARD_REGNO_MODE_OK, MODES_TIEABLE_P.  This leads me to believe that
composite modes aren't passed to FUNCTION_ARG whole, but split into
components first.

> An alternative would be to use the complex types, but I really don't like
> that since the complex types imply certain semantics when performing
> arithmetic.

No, complex modes are a bad fit.  Moreover, there are special
semantics associated with BPs.  Consider following a linked-list chain:

    struct foo {
	...
	struct foo *next;
	...
    };

    struct foo *foop;
    ...
    while (foop) {
	...
	foop = foop->next;
    }

The offset of member `next' is N bytes.  The size of a pointer is
PSIZE bytes.  A bounded pointer has three components: value, base and
extent.  The assignment of bounded `foop = foop->next' breaks down
like so: (assume for type-checking and pointer-arithmetic's sake that
that the components of foop have type (char*))

    foop.value  = *(char **) (foop.value + N)
    foop.base   = *(char **) (foop.value + N+PSIZE)
    foop.extent = *(char **) (foop.value + N+2*PSIZE)

Because foop.value is used in the RHS of all three parts, the
assignment of foop.value must come last, otherwise we'll be loading
the pointer value from foop->next, but loading the base & extent from
foop->next->next.  Therefore, we must copy BPs in reverse order.

At this point, given the fuzziness surrounding plans for assigning
structs to regs, I will go with the tried & true BP modes.

Greg


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