Are Clang’s builtin types interoperable with __m128 intrinsics?

Maybe I'm small brained but built in vector types align with heavily platform optimized libraries. Meaning you don't want this stuff implemented in the compilers front end. You want it handled in the compilers back end.

Performance is equivalent in both representations, but the important thing is being able to write

  vec4 c = a * 4 + b;

instead of

  vec4 c = vec4_add(vec4_mul(a, 4), b);

i.e. infix vs postfix order, with simple * and +/- operators etc. I would very much like to appeal to the Zig authors to see the beauty in the former expression compared to the latter, for a huge class of real-world mathematical applications.

If this wasn’t math code we’d refactor such code into helper functions, but somehow when it’s math we refuse to.

vec4 c = a * 4 + b;

vec4 c = vec4_add(vec4_mul(a, 4), b);

vec4 c = vec4_fma(4, a, b);

I think operator overloading should be fine even for puritans, as long the language requires the type to be numerical in a strict sense, and so they have a well defined semantics. So integers, floating point, complex numbers, vectors, matrices, etc.

How would the language require it to be numerical? For example, if you're defining complex numbers in a library, what would the compiler be checking about your ComplexNumber type before allowing you to define `+` for it?

A few ways. The compiler could enforce commutativity, associativity and other properties of those operators.

Another possible route is to require that all types contained within the exported types are also numerical, or have some specific set of operators defined.

Do you mean at the type level or also for the operational semantics? In the latter case it's undecidable.

Also, you mentioned matrices in the previous comment, but multiplication between matrices is not commutative.

It's undecidable if the language used to define operators is sufficiently expressive. Even simple syntactic constraints would work well enough for most scenarios, like "operators may only be defined by an expression containing other operators".

New types also don't have to inherit the properties of the operators they use.

In any case, my point was that there are multiple avenues to explore in providing operators in a way that don't compromise the compiler's ability to optimize numerical code.

The problem with operator overloading is not really numericity, IMO. The problems are:

- hidden control flow (function calls should look like function calls, an operation should never mask a function call)

- global weirdness. If a library changes the language, how does that affect some other code you're pulling in? Where do you effect those changes?

Some CPUs don't have a MUL or (like some 32-bit RISC architectures) DIV instruction, and on these, the C compile has to fall back to a function call.

You sure the compiler doesn't inline it? That an operator might take more than one opcode I think is uncontroversial

Multiplication takes more than a handful of instructions if the hardware doesn't do it.

https://godbolt.org/z/ccYPaz1Pj

For this example (AVR), this is the int multiply function __mulhi3:

    00: 00 24  eor  r0, r0
    02: 55 27  eor  r21, r21
    04: 00 c0  rjmp .+0
    06: 08 0e  add  r0, r24
    08: 59 1f  adc  r21, r25
    0a: 88 0f  add  r24, r24
    0c: 99 1f  adc  r25, r25
    0e: 00 97  sbiw r24, 0x00
    10: 01 f0  breq .+0
    12: 76 95  lsr  r23
    14: 67 95  ror  r22
    16: 00 f0  brcs .+0
    18: 71 05  cpc  r23, r1
    1a: 01 f4  brne .+0
    1c: 80 2d  mov  r24, r0
    1e: 95 2f  mov  r25, r21
    20: 08 95  ret

I mean, pedantically speaking the normal zig operators do control flow in their operators, in checked mode they panic on overflow, etc (you're not supposed to recover from them but I suppose it's possible). There's probably (internal) control flow in the saturating operators, etc.

Not always. I’ve seen division and atomic operations stay as function calls to libgcc. However, semantics of these are well-defined either way, unlike user-defined operators, so existence of a hidden call is at most an inconvenience when linking code from different compilers.

Your atomic increment may turn into a function call if it’s targeting multiple microarchitectures.

> hidden control flow (function calls should look like function calls, an operation should never mask a function call)

An operator is either a function call or some simple built-in operation.

Thus not hidden.

That syntactic elements that consist of symbols rather than alnum and that are used as prefix or infix operators are necessarily “not a function call” is just a rule that can be changed.

> An operator is either a function call or some simple built-in operation.

In theory, yes. In practice, an operator is a simple built-in operation 99.999% of the time, which lures programmers into thinking that's how it always is.

It's like a self-driving car that's safe 99.999% of the time but still requires you to continuously pay attention to take over at a second's notice.

Humans just don't work like that.

> In theory, yes. In practice, an operator is a simple built-in operation 99.999% of the time, which lures programmers into thinking that's how it always is.

Noo it isn’t. Many languages use something like `+` for string concatenation. Maybe list concatenation.

> - hidden control flow (function calls should look like function calls, an operation should never mask a function call)

You can restrict operator definitions to expressions containing other operators. Operators are now guaranteed to expose only as much control flow as the underlying operators would already expose.

> - global weirdness. If a library changes the language, how does that affect some other code you're pulling in? Where do you effect those changes?

I'm not sure what you mean. Behaviour depends on language semantics. You don't specify why operators are uniquely weird on this compared to literally any other function call when language semantics or library behaviour changes.