On Fri, Jun 2, 2023 at 11:24 AM Alexander Monakov <amona...@ispras.ru> wrote: > > > On Fri, 2 Jun 2023, Matthias Kretz wrote: > > > > Okay, I see opinions will vary here. I was thinking about our immintrin.h > > > which is partially implemented in terms of generic vectors. Imagine we > > > extend UBSan to trap on signed overflow for vector types. I expect that > > > will blow up on existing code that uses Intel intrinsics. > > > > _mm_add_epi32 is already implemented via __v4su addition (i.e. unsigned). So > > the intrinsic would continue to wrap on signed overflow. > > Ah, if our intrinsics take care of it, that alleviates my concern.
Just to add when generic vectors are lowered to scalar operations then signed vector ops become signed scalar ops which means followup optimizations will assume undefined behavior on overflow. > > > I'm not sure what you consider a breaking change here. Is that the implied > > > threat to use undefinedness for range deduction and other optimizations? > > > > Consider the stdx::simd implementation. It currently follows semantics of > > the > > builtin types. So simd<char> can be shifted by 30 without UB. The > > implementation of the shift operator depends on the current behavior, even > > if > > it is target-dependent. For PPC the simd implementation adds extra code to > > avoid the "UB". With nailing down shifts > sizeof(T) as UB this extra code > > now > > needs to be added for all targets. > > What does stdx::simd do on LLVM, where that has always been UB even on x86? > > Alexander
