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