JIT: check that constant handles are not OK2_CONST_LONGs

[AndyAyersMS]

Follow-up from #1788.

Also remove an arm-only handle block that should now be redundant.

[AndyAyersMS]

@briansull PTAL
cc @dotnet/jit-contrib

[AndyAyersMS]

The newly added assert is firing. Will dig in and see why.

[briansull]

There is a strange code sequence here, that may be relevant:

Assertionprop.cpp line 1341:

/* iconFlags should only contain bits in GTF_ICON_HDL_MASK */
assert((iconFlags & ~GTF_ICON_HDL_MASK) == 0);
assertion.op2.u1.iconFlags = iconFlags;
#ifdef _TARGET_64BIT_
if (op2->TypeGet() == TYP_LONG)
{
assertion.op2.u1.iconFlags |= 1; // Signify that this is really TYP_LONG
}
#endif // _TARGET_64BIT_

[AndyAyersMS]

Hmm, I should have checked the assertion unions more carefully -- the iconFlags overlay the top part of the long value (on a 32 bit host), so once an assertion is created, there's no easy way to check if somebody has inadvertently set the icon flags.

I suppose in a debug build we could keep some extra state?

[AndyAyersMS]

I suppose in a debug build we could keep some extra state?

Or perhaps just add padding to IntVal on 32 bits, so the icon flags aren't overlaying anything.

[briansull]

These flags should not overlap. I would suggest that we fix that.

[AndyAyersMS]

/AZP run runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

[AndyAyersMS]

After adding padding, no hits from the new assert in inner or outer loop testing. The padding should not increase the size of the assertion records.

The one remaining failure is in the flaky-seeming trace event test.

[briansull]

Looks Good

[briansull]

Don't really need the braces { } here.

[briansull]

I would add a break.

[briansull]

Should have a break here

[briansull]

LGTM

[AndyAyersMS]

Remaining failures are in the tracevent tests.