'refanytype' and 'sizeof' instructions are also pure

[jack-pappas]

I've added the refanytype and sizeof instructions to the list of instructions classified as side-effect-free. According to ECMA-335, 6th ed., sections III.4.22 and III.4.25, these instructions never raise exceptions and are always verifiable.

[brodyberg]

I checked the docs and they agree: no exceptions, always verifiable. Also, all the other instructions with the same information are already added so nothing else appears to be needed beyond this change.

[dsyme]

I agree that this is a safe change. I expect @latkin will request some indication for where this can give better code generation, and you will need to add a micro code-generation test for this case.

[latkin]

Well it seems like proper change. Does this manifest itself in any way besides calculations by --test:HasEffect switch? Is this stuff considered by general codegen, e.g. for inlining or something?

[jack-pappas]

I don't know the exact details of how this change would affect the F# code generation process, so I'll have to dig deeper on that. To speculate though, I'd guess that marking these instructions as "pure" gives the compiler leeway to re-order them w.r.t. to other code, or eliminate them if the compiler detects they're not used.

For example, take the following code:

leta=2+3letb= sizeof<int16>+3

The compiler should already know that it doesn't need to generate IL for the expression bound to a (assuming a isn't used later). It may not currently realize it can also eliminate the IL for b, because it doesn't know sizeof won't have an effect. The one thing we'll have to watch out for here is that while sizeof is pure, it shouldn't be eliminated in any compile-time constant-folding (think of sizeof<nativeint> or sizeof<'T> where 'T is a generic parameter).

I'll follow up on Don's suggestion about implementing some code-generation tests for this. Or, if anyone else has the desire (and spare cycles) to write the tests, that'd be even better.

[dsyme]

Hi @jack-pappas - Yes, in general, always submit tests with a PR (unless it is a code cleanup) :) We'll probably end up adopting a policy where PRs without tests just get closed - with a link to the guidelines - unless of course the PR says "tests to follow..." :)

I know that writing the tests can take 5x or 10x longer than making a fix, especially one of this kind. I have to budget that in whenever I make a fix - but equally @latkin can testify how many of my "fixes" have been busted due to inadequate testing on my part :)

[dsyme]

I believe you should see the effect in the full elimination of "let x = sizeof" in the generated optimized code for the following:

let f() = let x = sizeof<int>
3 + 4

Cheers
Don

[latkin]

If a codegen test can be added for this, seems ok to include in F# 4.0 as a bug fix.

[latkin]

Per the contribution guidelines, bug fixes should map to an existing issue, and include tests. Please re-open when these are in place.