Re: [PATCH] gen_lowpart and lvalues

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

    You'll notice that the copy_to_reg call in the REG case before it,
    also doesn't preserve the lvalue-ness of it's operand, and neither
    does the force_reg call of the ADDRESSOF shortly after.

    I'll admit that you'd given convincing arguments in the code that you
    quoted that there was a benefit of allowing gen_lowpart to preserve
    lvalueness, but a deeper investigation reveals that this is often
    either safe or a misunderstanding in the places that rely on it.

    Here in store_bit_field, for example, its always safe to use gen_lowpart
    to refer to the newly created pseudo register in a different mode.

I think we need to be very precise about the semantics of gen_lowpart.
Either it returns a lvalue or it doesn't.  I don't like saying that
"well it sometimes does and it sometimes doesn't, but the caller should
know which is the case for each call, so that's OK".

    Have you considered something as simple as, in the VIEW_CONVERT_EXPR
    case in expr.c's expand_expr_real moving the gen_lowpart call a few
    lines further down inside the GET_CODE (op0) != MEM?  

There are a lot of ways to fix this, but all of them depend on agreeing
on a precise definition of what it is that gen_lowpart returns.
If you want to say that gen_lowpart only returns an rvalue but
gen_lowpart_common returns an lvalue, that's probably fine, but we
do need to be explicit about it and document what we decide!