On Mon, Jun 13, 2011 at 5:17 AM, Mike Stump <[email protected]> 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.
