https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Now verified, in the LTO case both wi::gt_p/wi::gtu_p and wi::lt_p/wi::ltu_p
are inlined and do:
0x000000000191600e
<_ZNK14range_operator16wi_fold_in_partsER6irangeP9tree_nodeRK16generic_wide_intI16wide_int_storageES8_S8_S8_+750>:
test %rdx,%rdx
0x0000000001916011
<_ZNK14range_operator16wi_fold_in_partsER6irangeP9tree_nodeRK16generic_wide_intI16wide_int_storageES8_S8_S8_+753>:
je 0x1915edc
<_ZNK14range_operator16wi_fold_in_partsER6irangeP9tree_nodeRK16generic_wide_intI16wide_int_storageES8_S8_S8_+444>
0x0000000001916017
<_ZNK14range_operator16wi_fold_in_partsER6irangeP9tree_nodeRK16generic_wide_intI16wide_int_storageES8_S8_S8_+759>:
cmp $0x3,%rdx
0x000000000191601b
<_ZNK14range_operator16wi_fold_in_partsER6irangeP9tree_nodeRK16generic_wide_intI16wide_int_storageES8_S8_S8_+763>:
ja 0x1915edc <_ZNK14range_operator
so that looks like lh_range.val[0] != 0 && lh_range.val[0] <= 3U, so I'm pretty
sure that is the STATIC_CONSTANT_P case.
