This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: WITH_SIZE_EXPR
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: rth at redhat dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 20 Jul 04 14:33:46 EDT
- Subject: Re: WITH_SIZE_EXPR
> I don't see the
> difference of whether the value (whatever it represents) is stored in
> the ARRAYR_REF or WITH_SIZE_EXPR.
The fact that you've got to look in two places to decompose an array_ref
into pointer arithmetic doesn't sound like a bad idea to you?
Sorry, you misunderstood what I meant.
Was I was proposing is that array_ref_element_size, instead of looking
at TREE_OPERAND (exp, 3) should see if TREE_OPERAND (exp, 0) was a
WITH_SIZE_EXPR and, if so, get the size from operand 1 of that.
We should be using CALL_EXPR_HAS_RETURN_SLOT_ADDR here.
Indeed. I hadn't heard of it until just now. It looks like it's only
set in the C++ front end and only used in two places. However, this indeed
looks like it's very relevant here. Are you suggesting that
gimplification should do something with it?
Unfortunately, introducing a variable-sized temporary early is tricky
to get rid of later,
Oh, certainly. But look at the lang hook I recently added for a maxium
type size: that was motivated by just this issue.