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.
But the documentation of TARGET_PROMOTE_FUNCTION_MODE would help with
some clarification, which is also on my TODO, if only I understood it
clearly ;-)
Let me quote the text and add my commentary
Target Hook: |machine_mode| *TARGET_PROMOTE_FUNCTION_MODE
*>
> Like |PROMOTE_MODE|, but it is applied to outgoing function arguments
or function return values.
This implies it is for arguments in caller side but not clear about
return values for caller or callee ?
> for_return allows to distinguish the promotion of arguments and
return values.
> If it is |1|, a return value is being promoted and
|TARGET_FUNCTION_VALUE| must perform the same promotions done here.
This clearly implies incoming return value in caller.
> If it is |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 |promote_mode|,
though the signedness may be different.
This seems to imply incoming args in callee or outgoing result in callee.
Assuming my interpretation is correct, for BPF we want @for_return=1 to
promote but only part of @for_return=2 to promote as well - this means
pushing down outgoing from one level up into here. I can do this but
just to make sure if I understand this correctly.
Thx,
-Vineet
