[tree-ssa] RFC: Never gimplify ASM_EXPRs

[Jason Merrill]

On Thu, 05 Jun 2003 14:49:10 -0700, Zack Weinberg <zack@codesourcery.com> wrote:

> Richard Henderson <rth@redhat.com> writes:
>
>> The "addressiness" of md builtin parameters should not be a problem
>> in the same way as asms, since they can represent the argument as a
>> reference parameter, at which point you'll just DTRT.
>
> What stops us from doing that for "m" parameters to asms?

Well, we aren't going through the frontend argument conversion code.  But
I'd be happy to say that an 'm' input operand must be a reference to
memory.

Implementing a lesser requirement, that an 'm' input operand must be an
lvalue, causes two testcases to fail:

gcc.c-torture/compile/20010526-1.c passes "&d"
gcc.dg/20011029-2.c passes "a", where a is an array.  a[0] would be a valid
  operand, but a by itself is not.

In both of these cases, the operand is an address rather than a reference.
The compiler on the trunk accepts these operands and copies them into temp
slots so that they're in memory.  I suppose it's possible that the first
testcase could be testing exactly that, but it seems pretty clear to me
that the usage in the second test is a bug.

Do people think that we ought to accept this sort of usage, or is it
reasonable to require that an 'm' input operand be an lvalue?

Jason