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 ?
Thx,
-Vineet
