[PATCH] D11861: [IR] Add token types

[Sanjoy Das via llvm-commits]

On Mon, Aug 10, 2015 at 11:41 AM, David Majnemer
<david.majnemer at gmail.com> wrote:
> majnemer added a comment.
>
> In http://reviews.llvm.org/D11861#220835, @sanjoy wrote:
>
>> Couple of questions
>>
>> - [obsolete -- I see you disallow the `token*` type] Can we load / store through a pointer of type `token *`, allocated on the heap, or created via `inttoptr`?
>> - Can we do this transform:
>>
>>   ``` if (cond) { %t0 = call token @p() call @consume(token %t0) } else { %t1 = call token @p() call @consume(token %t1) } ```
>>
>>   TO
>>
>>   ``` %t = call token (cond ? @p : @q)() call @consume(token %t) ```
>>
>>   ?
>
>
> I don't think such a transformation would be canonical because the call is now indirect.  Nevertheless, this wouldn't have an effect on my use case.  Which would you prefer?

I don't have a specific requirement on this, but perhaps this (that
the above xform is non-canonical) should be mentioned in the langref
or a test case?  This is one way the origin of the `token` typed value
may become obscured.

>
>
> ================
> Comment at: lib/Analysis/LoopInfo.cpp:211
> @@ -210,1 +210,3 @@
>    for (Loop::block_iterator I = block_begin(), E = block_end(); I != E; ++I) {
> +    if ((*I)->getType()->isTokenTy())
> +      return false;
> ----------------
> sanjoy wrote:
>> Just to be clear -- this is only conservatively correct, right?  IIUC, we should be able to clone token producing instructions as long as we do not introduce phis / selects.
> Correct.

How much work do you think it would be to have a more precise handling
of token types here?

So we can use the token type, as mentioned here, to implement operand
bundles.  The operand bundles themselves could be function calls that
return a `token`, and these get passed to the concerned call / invoke
as dummy arguments that are later dropped.  The deopt state could then
be represented as:

  %state = call token @deopt_state(...)
  call void @some_java_function(token %state, real_arg_0, real_arg_1, ...)

This is similar to the scheme we use internally, except that instead
of a `token` type, we use i32.  This causes issues with LLVM
generating phis and selects between the call to @deopt_state and the
call to @some_java_function which will be avoided by using token
types.

However, we cannot use the token scheme if it, for instance, disables
loop unrolling and loop unswitching.  The deopt states need to persist
in the IR from the very beginning and there are quite a few of them,
and therefore they should not inhibit meaningful optimization.

-- Sanjoy