Implement permanent solution to integrate simd64 type to VecCon node

[DeepakRajendrakumaran]

As part of zmm support implementation, we are using a workaround to represent simd64 type in VecCon node. This was due to some issues with increased node size causing issues in JIT.

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

---

As part of zmm support implementation, we are using a workaround to represent simd64 type in VecCon node. This was due to some issues with increased node size causing issues in JIT.

Author:	DeepakRajendrakumaran
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[SingleAccretion]

I suspected we would eventually hit something like this issue. There is another related problem: VN memory consumption. Generally, for a single unique vector constant in VN, we will use 3 * sizeof(SIMD) memory (one in the chunk, two for the hash table (including amortized growth cost)).

I think it would make a lot of sense to use a table for the vector constants, similar to how ClassLayout instances are handled today.

[tannergooding]

This was resolved and VecCon directly tracks a simd64_t field on xarch.

@SingleAccretion, could you open a separate issue to track the VN improvement if you think that's worth pursuing longer term?