You stub out the few architecture specific routines you need and let someone write them for their architecture in asm if it doesn't exist already.

A minimal porting effort for the best of all worlds.

The best of all worlds, except that you lose your optimizations.

I would like to see the benchmarks before I agreed to that.

You might not get the best optimization possible if you have to leave it up to the C compiler with inline assember... But that mix worked well for C and C++.

And rust can still optimize things like deciding which integer optimizations need the overflow check, and only add it where static analysis failed.

No, it doesn't work well for C and C++ at all. Turn off InstCombine and see what performance you get in LLVM for an idea of what will happen if the compiler doesn't know about the semantics of + and -.

We are only talking about a subset of additions and subtractions to begin with.

How often will idiomatic rust code need overflow checks?

Also, if the UB operations are defined by target assembler (instead of in C++) then you may not even need extra overflow checks, depending on the assembler semantics. This would only be needed in the places where static analysis failed, of course.

One could also use the native compiler options, if available, to avoid the issue alltogether (like -fwrapv).

> We are only talking about a subset of additions and subtractions to begin with.

No, you're talking about all signed addition.

> How often will idiomatic rust code need overflow checks?

You'd be surprised. Go look at the implementations of containers in the standard library.

> Also, if the UB operations are defined by target assembler (instead of in C++) then you may not even need extra overflow checks, depending on the assembler semantics. This would only be needed in the places where static analysis failed, of course.

I don't know what this means exactly. If you're saying you should implement a static analysis to try to eliminate unneeded overflow checks, then this is a huge burden.

> One could also use the native compiler options, if available, to avoid the issue alltogether (like -fwrapv).

If you're dependent on GCC/clang extensions to C, then you're not compiling to C. You're compiling to a front end to GIMPLE/LLVM. At that point there's no benefit over just compiling to GIMPLE or LLVM in the first place.

> No, you're talking about all signed addition.

No, I'm talking about the ones that won't overflow. Some can be statically shown to not need a runtime check.

> If you're dependent on GCC/clang extensions to C, then you're not compiling to C.

I'm not saying that. I'm saying require either the target compiler (which the user is in control of) to provide a flag to give signed overflow the proper semantics (which would be useful if the user happens to be using clang or gcc), or fall back to requiring some asm for the target system which provides the needed semantics.

This would all be up to someone to configure for the target machine. Not a big deal once per architecture.

> At that point there's no benefit over just compiling to GIMPLE or LLVM in the first place.

Well if GIMPLE or LLVM was available for all of the targets that C compilers are, then I'd agree.

But they aren't. So I don't.

I think these extensions:

https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins...

could be implemented in plain C if you're careful. It's not like the other extensions like __builtin_constant_p or asm that'd leave you stuck with GNU C.

And besides, GNU C is good enough for lots of people!

A lot of the claimed benefits of compiling to C--compilation to embedded targets without a GCC backend, most importantly--evaporate if you only compile to GCC's dialect of C. It's another way in which compiling to C ends up worse in the long run.