https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123286
--- Comment #6 from XChy <xxs_chy at outlook dot com> --- > The only stable thing here is to use the gimple front-end really. > And note RTL optimizations are still part of the middle-end in GCC terms; > even though the RTL that gets optimized is usually backend depedent it is > still common code. Surprised, I assumed that RTL in GCC is similar to SelectionDAG in LLVM. So RTL is low-level but is still generic. > So things like vqadd_u64 constant folding happens in the RTL level of GCC's > middle-end. RTL SS_PLUS/US_PLUS/SS_MINUS/US_MINUS is used to represent the > saturated add/minus. It just that SS_PLUS/US_PLUS/SS_MINUS/US_MINUS is > older than SAT_ADD and the simplifications on the rtl level is still newish > too; added r12-4231-g555fa3545efe23. SAT_ADD on the gimple-level was only > added in r15-576-g52b0536710ff3f. And vqadd_u64 being done as SAT_ADD was > done with r15-7018-gaa361611490947 though SS_PLUS has been used since the > aarch64 backend was added. > > So you can see using vqadd_u64 was not stable to use in the first place. > Especially pre GCC 12. It sounds a pity that there is no stable middle-end optimization barrier at the language level. Anyway, thanks for your detailed information!
