Re: Questions on PROMOTE_MODE, function_promote_mode

On 3/23/2026 11:25 AM, Vineet Gupta wrote:
>
>
> On 3/12/26 6:40 PM, H.J. Lu wrote:
>> On Thu, Mar 12, 2026 at 6:26 PM Vineet Gupta <[email protected]> 
>> wrote:
>>> On 3/12/26 6:01 PM, H.J. Lu wrote:
>>>>>>>> Please try this enclosed patch.
>>>>>>> Awesome, it does work perfectly for the tripping tests before. 
>>>>>>> I'll give
>>>>>>> it more extensive testing but this looks promising already.
>>>>>> If it works, please update the comment to explain that it is done 
>>>>>> for
>>>>>> compatibility
>>>>>> reasons.
>>>>> Sorry care to elaborate, comment for which part ?
>>>>> Compatibilty between gcc and llvm ? That's just the trigger,
>>>>> conceptually it is for implementing a certain ABI.
>>>> diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc
>>>> index 4773d789d8e..6f41a9e843c 100644
>>>> --- a/gcc/config/bpf/bpf.cc
>>>> +++ b/gcc/config/bpf/bpf.cc
>>>> @@ -299,13 +299,14 @@ bpf_file_end (void)
>>>>    static rtx
>>>>    bpf_function_value (const_tree ret_type,
>>>>             const_tree fntype_or_decl,
>>>> -         bool outgoing ATTRIBUTE_UNUSED)
>>>> +         bool outgoing)
>>>>    {
>>>>      enum machine_mode mode;
>>>>      int unsignedp;
>>>>
>>>>      mode = TYPE_MODE (ret_type);
>>>> -  if (INTEGRAL_TYPE_P (ret_type))
>>>> +  /* NB: Treat the callee's return value as unpromoted.  */
>>>> +  if (outgoing && INTEGRAL_TYPE_P (ret_type))
>>>>        mode = promote_function_mode (ret_type, mode, &unsignedp,
>>>>                 fntype_or_decl, 1);
>>>>
>>>> is needed only if callee doesn't always extend the return value.
>>> Right, for BPF we don't want callee to *ever* extend since that caller
>>> is expected to do that.
>>> The ABI which we are trying to implement is: Caller to promote/extend
>>> both args and return.
>>> I think this is atypical since callers args typically implies callee
>>> return but BPF has cross calling into and from x86 code thus it 
>>> needs to
>>> ensure this on both sides in BPF.
>>>
>>>
>>>> I assume
>>>> that GCC will be changed to always extend the return value in callee.
>>> You mean common code going fwd or do you imply something about BPF 
>>> code,
>>> sorry if I sound dense !
>>>
>>>> If
>>>> it is incorrect, you need to avoid extending the callee return 
>>>> value in
>>>> TARGET_PROMOTE_FUNCTION_MODE.
>>> The ABI being implemented expects caller to do promote/extend so no
>>> point in doing it in callee.
>> Try this patch then.
>>
>> diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc
>> index 4773d789d8e..e74302a928a 100644
>> --- a/gcc/config/bpf/bpf.cc
>> +++ b/gcc/config/bpf/bpf.cc
>> @@ -302,13 +302,7 @@ bpf_function_value (const_tree ret_type,
>>               bool outgoing ATTRIBUTE_UNUSED)
>>   {
>>     enum machine_mode mode;
>> -  int unsignedp;
>> -
>>     mode = TYPE_MODE (ret_type);
>> -  if (INTEGRAL_TYPE_P (ret_type))
>> -    mode = promote_function_mode (ret_type, mode, &unsignedp,
>> -                  fntype_or_decl, 1);
>> -
>>     return gen_rtx_REG (mode, BPF_R0);
>>   }
>
> But this now contradicts documentation which says 
> TARGET_PROMOTE_FUNCTION_MODE for_return=1 needs to do match 
> TARGET_FUNCTION_VALUE promotion.
> I'm updating the documentation for this hook anyways, can also add the 
> caveat that it "typically matches ...."
>
> If I got your attention, can you please also explain the semantics of 
> for_return=2 for  TARGET_PROMOTE_FUNCTION_MODE.
> It was introduced with following commit
> 2009-08-12 666e3cebe13c tm.texi (TARGET_PROMOTE_FUNCTION_MODE): Add 
> documentation for for_return == 2.
>
> +If it is @code{2}, the returned mode should be that of the register in
> +which an incoming parameter is copied, or the outgoing result is 
> computed;
> +then the hook should return the same mode as @code{promote_mode}, though
> +the signedness may be different.
>
> Is this to distinguish caller vs. callee side args or results. Or if 
> this is to distinguish copies and not actual args/results, why are 
> they special ?
Looks like it was related to pointer extension on itanic.

https://gcc.gnu.org/pipermail/gcc-patches/2009-August/267858.html

Jeff