3 ms·
One thing I really want in my compilers is a way to express expectations: if I expect an auto-vectorisation, or a block of unreachable code, I should be able to
by andrewaylett 3y ago
One thing I really want in my compilers is a way to express expectations: if I expect an auto-vectorisation, or a block of unreachable code, I should be able to tell the compiler explicitly!
For dead code, this is different from assertions, or Rust's `unreachable!` macro, in that they tell the compiler to trust me, and crash at runtime if I'm wrong. I want the compiler to check my logic and fail to compile if it can't prove me right. If I write a switch block and I know that only a limited subset of values can possibly happen, I still have to provide code for all possible values. But I expect that code to be subject to dead code elimination, and I'd quite like to be sure that actually happens. I'm not aware of any automation around checking that code I expect to compile to SIMD actually winds up doing that.
- The_Colonel 3y agoWhat does the compiler do with that expectation? If the code can't be vectorized for target architecture, does it emi a warning?
- andrewaylett 3y agoI'd quite like it to emit an error and fail. If some target architectures won't vectorise the code, I can always add the expectation conditionally. I'm not so much trying to catch deliberate changes, where a warning might make sense as I'd be (maybe) looking for it, but changes that break autovectorisation as a side effect -- maybe something can't be inlined any more, maybe a new compiler version introduces a new optimisation that causes a cascade of tiny changes. I'd hope that we would catch the difference in performance, but it's easier to notice a compilation failure than a performance drop.