new alias sets from the backend

Richard Henderson
Mon Sep 21 01:36:00 GMT 1998

On Mon, Sep 21, 1998 at 12:32:30AM -0600, Jeffrey A Law wrote:
> But don't you also have to deal with pointers within the va list?

I don't think so, and even if we did so long as they are all in
the same alias set we're fine -- the operations will be strictly

> ie, one arg could be an address of another arg in the va_list which
> was flushed to the stack.  So you have to go beyond just loads from
> va_list, you have to track how they're used later.

Huh?  Show me.  I don't think you can set that up.

Local storage, both spill and declared variables, are outside
both the argument spill area and the normal argument stack space.  

What you are suggesting sounds a bit like

	extern void foo(int *xp, int x);
	foo(stack_pointer - 4, 2);

and then expecting xp == &x inside foo.  Which I dare say goes
well outside the bounds of the reasonable.  To compound it all,
the only things that will exist in the va_list set are in the
elipsis of the function prototype, and so have no other name
by which they could be known.

My current thoughts on implementing this are not to rely on tagging
the value returned from va_start, but instead to introduce a new
builtin function to properly tag the memory reference.  Otherwise
weget into trouble if the va_list value is tucked away in memory,
lost, then recovered and used.  Something like 

#define va_arg(__va, __type)						\
__builtin_va_arg(							\
 *(((__va).__offset += __va_tsize (__type)),				\
   (__type *)(void *)((__va).__base + (__va).__offset                   \
              - (((__builtin_classify_type (* (__type *) 0)             \
                   == __real_type_class) && (__va).__offset <= (6 * 8)) \
                 ? (6 * 8) + 8 : __va_tsize (__type)))))

Which would take a mem, tag it, and return it otherwise unchanged.


More information about the Gcc-patches mailing list