On Jun 12, 2011, at 3:55 AM, Richard Guenther wrote: > In almost all cases(*) the need for a lvalue VIEW_CONVERT_EXPR can be avoided > by moving the VIEW_CONVERT_EXPR to the rvalue assigned too it. Remember that > VIEW_CONVERT_EXPR always conver the full object and are not allowed to > change sizes. > > So, do you have an example?
Sure, take a divmod type of instruction.[1] It has two outputs, a div and a mod. The instruction operates on registers, and produces two completely independent values. But really, it is a general features of the built-in mechanism that Kenny and I are working on that some people would like to reuse for other ports. The general feature is that one can declare any argument to a built-in to be input only, output only or input/output. This nicely matches what I think quite of lot of machines do for assembly language semantics. The support isn't to match my machine, but rather to support building a port, in which 1 or more instructions have such parameters. Requiring memory is a non-starter, and in fact, we already have a scheme for memory_operand type things for the instructions that take memory. The scheme used for them is borrowed from C++, where we just declare that the built-in takes a reference type. This reuses most of the code paths from C++ and it seems to work nicely. I'd be tempting to use it for register references, but, in my current scheme for registers, I support data flow in, out and in/out at the tree level and at the rtl level. We believe this is nice from an optimizing perspective, and probably required to get the warnings about using uninitialized variables correct.
