Re: WITH_SIZE_EXPR

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    > For example, if it's added as a handled_components_p, then we can
    > eliminate the element size field of ARRAY_REF.

    Huh?  Not a chance -- element size != stride.

Well, sure, but it would be exactly the same as the current usage of operand
3 of ARRAY_REF: it's ostensibly the element size, but it can be used to
represent anything else that's needed (e.g., stride).  I don't see the
difference of whether the value (whatever it represents) is stored in
the ARRAYR_REF or WITH_SIZE_EXPR.
    
    > ... for example allowing the representation of a function returning
    > a variable-size object, which we currently can't represent.

    You mean size unknown to the caller?  You're right, we can't represent
    that.  We NEVER WILL be able to represent that.  It makes NO SENSE.

There are two cases.  One is a size that's known to both, but not a
compile-time constant.  In that case, the MODIFY_EXPR is converted into a
call to memcpy.  But one operand of the memcpy is an ADDR_EXPR of the call.
However, when we gimplify that, we try to make a temporary of that size,
which aborts and if you remove the abort you get an infinite recursion.

The other case is where the object is of variable size and unknown to
the called, but a (small) maximum size is known.

    What you wanted to do was return a pointer to an object allocated out
    of the heap.  Your mistake was not realizing that you actually wanted
    to return a fixed sized pointer-type object.

No, you don't want to use the heap here.  There is a significant penalty
in heap allocation in tasking environments on many system.  The reason for
allowing the variable-size return was precisely to avoid the heap allocation!

    > What are your thoughts?

    That W_S_E is pretty nasty and should not escape current usage.  That
    we might be able to get rid of it now that variable sized objects are
    always passed by reference, by exposing the temporaries involved.

That was basically the heart of my question: whether you were viewing it
as a kludge that would hope to be gotten rid of or whether you were thinking
of it as a mechanism that would become the preferred way to handle lots of
things.

My tendency was initially to treat it as a kludge too, but I realized that if
there was no way to avoid it in one case, we might as well make as much
out of it as we can.