Am Donnerstag, den 18.10.2018, 20:53 +0100 schrieb Richard Sandiford:
> "Uecker, Martin" <martin.uec...@med.uni-goettingen.de> writes:
> > Hi Richard,
> >
> > responding here to a couple of points.
> >
> > For bignums and for a type-descibing type 'type'
> > there were proposals (including from me) to implement
> > these as variable-sized types which have some restrictions,
> > i.e. they cannot be stored in a struct/union.
>
> But do you mean variable-sized types in the sense that they
> are completely self-contained and don't refer to separate storage?
> I.e. the moral equivalent of:
>
> 1: struct { int size; int contents[size]; };
>
> rather than either:
>
> 2: struct { int size; int *contents; };
I was thinking about 1 not 2. But I would leave this to the
implementation. If it can unwind the stack and free
all allocated storage automatically whenever this is
necessary, it could also allocate it somewhere else.
Not that this would offer any real advantage...
In both cases the only real problem is when storing
these in structs. So this should simply be forbidden
as it is for VLAs.
> or:
>
> 3: union {
> // embedded storage up to N bits (N constant)
> // description of separately-allocated storage (for >N bits)
> };
This is essentially an optimized version of 2.
> ? If so, how would that work with the example I gave in the earlier
> message:
>
> bignum x = ...;
> for (int i = 0; i < var; ++i)
> x += x;
>
> Each time the addition result grows beyond the original size of x,
> I assume you'd need to allocate a new stack bignum for the new size,
> which would result in a series of ever-increasing allocas. Won't that
> soon blow the stack?
That depends on the final size of x relative to the size of the stack.
But this is no different to:
for (int i = 0; i < var; ++)
{
int x[i];
}
or to a recursive function. There are many ways to exhaust the
stack. It is also possible to exhaust other kinds of resources.
I don't really see the problem.
> Option 3 (as for LLVM's APInt) seems far less surprising, and can
> be made efficient for a chosen N.
Far less surprising in what sense?
> What makes it difficult for C
> isn't the lack of general variable-length types but the lack of
> user-defined contructor, destructor, copy and move operations.
C already has generic variable-length types (VLAs). So yes,
this is not what makes it difficult.
Yes, descructors would be needed to make it possible to store
these types in struct without memory leakage. But the destructors
don't need to be user defined, it could be a special purpose
destructor which only frees the special type.
But it doesn't really fit in the way C works and I kind of like
that C doesn't do anything behind my back.
Best,
Martin
> Thanks,
> Richard
>
> > Most of the restrictions for these types would be the same
> > as proposed for your sizeless types.
> >
> > Because all these types fall into the same overall class
> > of types which do not have a size known at compile
> > time, I would suggest to add this concept to the standard
> > and then define your vector types as a subclass which
> > may have additional restrictions (no sizeof) instead
> > of adding a very specific concept which only works for
> > your proposal.
> >
> > Best,
> > Martin
> >
> >
> >
> >
> >
> > Am Donnerstag, den 18.10.2018, 13:47 +0100 schrieb Richard Sandiford:
> > > Joseph Myers <jos...@codesourcery.com> writes:
> > > > On Wed, 17 Oct 2018, Richard Sandiford wrote:
> > > > > Yeah, can't deny that if you look at it as a general-purpose
> > > > > extension.
> > > > > But that's not really what this is supposed to be. It's fairly
> > > > > special
> > > > > purpose: there has to be some underlying variable-length/sizeless
> > > > > built-in type that you want to provide via a library.
> > > > >
> > > > > What the extension allows is enough to support the intended use case,
> > > > > and it does that with no enforced overhead.
> > > >
> > > > Part of my point is that there are various *other* possible cases of
> > > > non-VLA-variable-size-type people have suggested in WG14 reflector
> > > > discussions - so any set of concepts for such types ought to take into
> > > > account more than just the SVE use case (even if other use cases need
> > > > further concepts added on top of the ones needed for SVE).
> > >
> > > [Answered this in the other thread -- sorry, took me a while to go
> > > through the full discussion.]
> > >
> > > > > > Surely, the processor knows the size when it computes using these
> > > > > > types, so one could make it available using 'sizeof'.
> > > > >
> > > > > The argument's similar here: we don't really need sizeof to be
> > > > > available
> > > > > for vector use because the library provides easy ways of getting
> > > > > vector-length-based constants. Usually what you want to know is
> > > > > "how many elements of type X are there?", with bytes just being one
> > > > > of the available element sizes.
> > > >
> > > > But if having sizeof available makes for a more natural language
> > > > feature
> > > > (one where a few places referencing VLAs need to change to reference a
> > > > more general class of variable-size types, and a few constraints on
> > > > VLAs
> > > > and variably modified types need to be relaxed to allow what you want
> > > > with
> > > > these types), that may be a case for doing so, even if sizeof won't
> > > > generally be used.
> > >
> > > I agree that might be all that's needed in C. But since C++ doesn't
> > > even have VLAs yet (and since something less ambituous than VLAs was
> > > rejected) the situation is very different there.
> > >
> > > I think we'd need a compelling reason to make sizeof variable in C++.
> > > The fact that it isn't going to be generally used for SVE anyway
> > > would undercut that.
> > >
> > > > If the processor in fact knows the size, do you actually need to
> > > > include
> > > > it in the object to be able to provide it when sizeof is called? (With
> > > > undefined behavior still present if passing the object from a thread
> > > > with
> > > > one value of sizeof for that type to a thread with a different value of
> > > > sizeof for that type, of course - the rule on VLA type compatibility
> > > > would
> > > > still need to be extended to apply to sizes of these types, and those
> > > > they
> > > > contain, recursively.)
> > >
> > > No, if we go the undefined behaviour route, we wouldn't need to store it.
> > > This was just to answer Martin's suggestion that we could make sizeof(x)
> > > do the right thing for a sizeless object x by storing the size with x.
> > >
> > > Thanks,
> > > Richard
