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.
>
> 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 ?

Thx,
-Vineet