[vector] Vector.cast
John Rose
john.r.rose at oracle.com
Wed May 30 21:21:03 UTC 2018
On May 30, 2018, at 11:45 AM, Lupusoru, Razvan A <razvan.a.lupusoru at intel.com> wrote:
>
> On one side, there are benefits to doing this since it makes behavior easier to understand since size would stay the same. On the other side, we have it working and fully tested with current approach so at least we have some confidence that implementation is fine. So I am a bit torn from my side - but it feels like the right thing would be to keep lane same and thus force resize to be explicit (and thus make it less of an error for developer bugs).
Let's take both kinds of benefits: API simplification and your
enhanced transforms. Getting both requires us to think a
little more about what API might best describe the operations
which change length.
On way I like to think about this sort of problem is to work
backward from a concrete instruction sequence I want.
Start by imagining it as a special standalone concrete intrinsic.
It will probably be very ugly. Then factor it as a composition
multiple sub-operations, each of which can be described in a
more abstract, mathematical way. Ask, "could the JIT see the
composition of these operations and select the instruction I
actually want?" If the answer is yes, the continue refining
the sub-operations. In the end, only the sub-operations
show up as primitives in the user model. As a final step,
ensure that the user model encourages coders to use the
API operations in combinations which are likely to select
good instructions; use javadoc, name choices, code examples,
whatever it takes. Lather, rinse, repeat.
— John
More information about the panama-dev
mailing list