> Am 19.05.2026 um 15:17 schrieb Jeffrey Law <[email protected]>:
>
>
>
>> On 5/19/2026 12:14 AM, Richard Biener wrote:
>>> On Mon, May 18, 2026 at 4:37 PM Raphael Zinsly
>>> <[email protected]> wrote:
>>>
>>> On Fri, May 15, 2026 at 10:09 AM Richard Biener <[email protected]> wrote:
>>>> On Wed, 13 May 2026, Raphael Moreira Zinsly wrote:
>>>> ...
>>>>> +/* Simplify (a < 0) ? ARG1 OP CONST : ARG1 to ((a < 0) ? 0 : CONST) OP
>>>>> ARG1
>>>>> + when CONST is a 2^n-1 constant. */
>>>>> +(for op (plus bit_ior bit_xor)
>>>>> + (simplify
>>>>> + (cond (lt @0 integer_zerop@1) (op:c @2 INTEGER_CST@3) @2)
>>>> No :c necessary on 'op'
>>>>
>>> Ok.
>>>
>>>>> + (if (wi::exact_log2 (wi::to_wide (@3) + 1) != -1)
>>>> Why is it cheap to splat the sign bit? If it's cheap to splat
>>>> the sign bit it's cheap to select between zero and a constant:
>>>> <splat-sign-bit-to-full-width> & COSTANT.
>>>>
>>>> That you leave in the (cond ...) hints strongly in that it's
>>>> an oddly special "canonicalization" and that it is really
>>>> a target dependent RTL thing?
>>>>
>>> It is a canonicalization, but I believe it's worth it.
>>> The message of this commit is misleading, which is my mistake, I was so
>>> immersed in trying to generate a splat sign bit that I kept the original
>>> commit description without much thought.
>>> I'm in fact generating a conditional move that can be transformed into a
>>> splat sign bit in the targets that benefit from it.
>>> I will describe it better in V2.
>>>
>>> The current code produces for 'c < 0 ? a : a + 7':
>>>
>>> if (c_2(D) >= 0)
>>> goto <bb 3>;
>>> else
>>> goto <bb 4>;
>>>
>>> <bb 3>
>>> _4 = a_3(D) + 7;
>>>
>>> <bb 4>
>>> # _1 = PHI <a_3(D)(2), _4(3)>
>>> return _1;
>>>
>>> After this patch we get:
>>>
>>> _1 = c_2(D) < 0;
>>> _4 = _1 ? 0 : 7;
>>> _8 = a_3(D) + _4;
>>> return _8;
>>>
>>> Is it reasonable?
>> I think so. But as said, why only for 7 and not for 42?
> 2^n-1 is interesting because there's a highly generic way to synthesize that
> sequence. It's just two shifts. So long as you have a barrel shifter,
> that's going to be pretty efficient. Arbitrary constants aren't as clear cut
> as you have to worry about whether or not the nonzero constant can be encoded
> by the target.
>
> Granted we're in gimple, so one could make an argument that these are low
> level issues that aren't applicable.
>
> The way I've generally encouraged folks to think about these transformations
> is to look at both gimple and RTL simplification. I think in this case we
> were initially looking at the RTL side of things, then concluded the idea was
> sound for gimple without too much consideration for whether or not it ought
> to be generalized to more constants in gimple.
Ok, we’re not making such distinction elsewhere in GIMPLE and if it’s supposed
to be a canpnicalization then it’s odd to do it only for special constants.
And if it’s a target specific thing it belongs to RTL expansion or RTL ifvct.
IMHO.
Richard
> jeff
>
