Questions on PROMOTE_MODE, function_promote_mode

[Vineet Gupta]

On 3/12/26 6:40 PM, H.J. Lu wrote:
> On Thu, Mar 12, 2026 at 6:26 PM Vineet Gupta <vineet.gupta@linux.dev> 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.

Indeed this gets the similar results while the implementation matches 
better with ABI specification.

I do have a couple of follow up questions.

1. This patch working seems to imply that TARGET_PROMOTE_FUNCTION_MODE 
directly doesn't affect the return value promotion. But that doesn't 
match the documentation. Granted TARGET_FUNCTION_VALUE was indirectly 
using it, but I'd consider that an implementation detail.

2. Why is PROMOTE_MODE adjustment necessary for this work, why can't 
stuff be promoted from say QI to DI directly ?

Thx,
-Vineet