[mypyc] Implement float abs primitive

[TH3CHARLie]

related mypyc/mypyc#644, also part of the plan to speed up rest of the slow microbenmark ops

Implement builtins.abs on float.

[TH3CHARLie]

on float_abs:

before:

interpreted: 0.434341s (avg of 5 iterations; stdev 1.5%)
compiled:    0.423638s (avg of 5 iterations; stdev 2.3%)

compiled is 1.025x faster

after:

interpreted: 0.422043s (avg of 5 iterations; stdev 1%)
compiled:    0.145499s (avg of 5 iterations; stdev 1.9%)

compiled is 2.901x faster

I'd like to add a run test for this, but looks like abs lacks in the testing shed

[JukkaL]

I'd like to add a run test for this, but looks like abs lacks in the testing shed

You can add abs to mypyc/test-data/fixtures/ir.py. Since SupportsAbs is not available, it's fine to use an overloaded function (int -> int and float -> float) instead.

[JukkaL]

Looks good, but it would be nice to have a test case for this (see my other comment).

[JukkaL]

Hmm the result of abs(0) should be of type int. Can you check that the return value is not a float here? You may need to add a similar primitive for abs(integer).

[TH3CHARLie]

This line is incorrect, it should be abs(0.0) == 0.0 while the test will pass because it gets interpreted and 0 == 0.0 returns True. It should be fixed now.

I am not getting what do you mean by adding a primitive for integer? Do you mean a fixture function or a mypyc primitive?

[JukkaL]

I mean a primitive for abs(5), where the argument is an integer (in int_ops.py). It can use PyNumber_Absolute for now, similar to the float op, but the return type would be int instead of float.

I think that we may currently use the float variant of the primitive for integer arguments, which doesn't seem right. More generally, it's better for consistency to also cover the int case.

[TH3CHARLie]

I see. I've verified that in the above case, abs(0) returns an int by checking the generated code and running the compiled module. So we wouldn't be using float variant for integer arguments.

The integer version primitive would better be implemented in a separate PR as it requires casts from CPyTagged to PyObject * if we are going to reuse PyNumber_Absolute

[JukkaL]

Doing this in a separate PR sounds good. I was worried that we might use the float op with an int argument since int is compatible with float. Thanks for checking that this isn't a real issue.

Implementing the integer variant in IR build would be even better, since it would avoid boxing/unboxing. Can you create a follow-up issue about this (or PR)? However, using PyNumber_Absolute would be a reasonable intermediate step.

[TH3CHARLie]

We are on the same track. By building the op in irbuild, we can have a fast path for short ints.