Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10))

[Richard Guenther <richard.guenther@gmail.com>]

On Mon, Jun 13, 2011 at 5:17 AM, Mike Stump <mikestump@comcast.net> wrote:
> 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.

That's not exactly an example - I can't think of how you want or need
to use VIEW_CONVERT_EXPRs to implement said divmod instruction or why
you would need
anything special for the _argument_ of said instruction.  An
instruction or call with multiple outputs would simply be something
like

{ div_1, mod_2 } = __builtin_divmod (arg_3);

with two SSA defs. A nice representation for the tree for { div_1,
mod_2 } remains to be found (if it should be a single tree at all, or
possibly
multiple ones).

We already play tricks for sincos for example via

tem_1 = __builtin_cexpi (arg_2);
sin_3 = REALPART_EXPR <tem_1>;
cos_4 = IMAGPART_EXPR <tem_1>;

which avoids the two defs by using a single def which is then decomposed.

So, can you elaborate a bit more on what you want to do with special
argument kinds?  Elaborate with an actual example, not words.

Thanks,
Richard.