diff options
author | Jose E. Marchesi <jose.marchesi@oracle.com> | 2022-08-24 13:07:57 +0200 |
---|---|---|
committer | Jose E. Marchesi <jose.marchesi@oracle.com> | 2022-08-24 15:25:18 +0200 |
commit | 6d1f144b3e6e3761375bea657718f58fb720fb44 (patch) | |
tree | 0eb2dd8800ffde34e12da51ecb02537eb806cbf2 /gcc/config/bpf | |
parent | f0f04e1dffea609cb74ac0b488385401ed7e15a3 (diff) | |
download | gcc-6d1f144b3e6e3761375bea657718f58fb720fb44.zip gcc-6d1f144b3e6e3761375bea657718f58fb720fb44.tar.gz gcc-6d1f144b3e6e3761375bea657718f58fb720fb44.tar.bz2 |
bpf: facilitate constant propagation of function addresses
eBPF effectively supports two kind of call instructions:
- The so called pseudo-calls ("bpf to bpf").
- External calls ("bpf to kernel").
The BPF call instruction always gets an immediate argument, whose
interpretation varies depending on the purpose of the instruction:
- For pseudo-calls, the immediate argument is interpreted as a
32-bit PC-relative displacement measured in number of 64-bit words
minus one.
- For external calls, the immediate argument is interpreted as the
identification of a kernel helper.
In order to differenciate both flavors of CALL instructions the SRC
field of the instruction (otherwise unused) is abused as an opcode;
if the field holds 0 the instruction is an external call, if it holds
BPF_PSEUDO_CALL the instruction is a pseudo-call.
C-to-BPF toolchains, including the GNU toolchain, use the following
practical heuristic at assembly time in order to determine what kind
of CALL instruction to generate: call instructions requiring a fixup
at assembly time are interpreted as pseudo-calls. This means that in
practice a call instruction involving symbols at assembly time (such
as `call foo') is assembled into a pseudo-call instruction, whereas
something like `call 12' is assembled into an external call
instruction.
In both cases, the argument of CALL is an immediate: at the time of
writing eBPF lacks support for indirect calls, i.e. there is no
call-to-register instruction.
This is the reason why BPF programs, in practice, rely on certain
optimizations to happen in order to generate calls to immediates.
This is a typical example involving a kernel helper:
static void * (*bpf_map_lookup_elem)(void *map, const void *key)
= (void *) 1;
int foo (...)
{
char *ret;
ret = bpf_map_lookup_elem (args...);
if (ret)
return 1;
return 0;
}
Note how the code above relies on the compiler to do constant
propagation so the call to bpf_map_lookup_elem can be compiled to a
`call 1' instruction.
While GCC provides a kernel_helper function declaration attribute that
can be used in a robust way to tell GCC to generate an external call
despite of optimization level and any other consideration, the Linux
kernel bpf_helpers.h file relies on tricks like the above.
This patch modifies the BPF backend to avoid SSA sparse constant
propagation to be "undone" by the expander loading the function
address into a register. A new test is also added.
Tested in bpf-unknown-linux-gnu.
No regressions.
gcc/ChangeLog:
PR target/106733
* config/bpf/bpf.cc (bpf_legitimate_address_p): Recognize integer
constants as legitimate addresses for functions.
(bpf_small_register_classes_for_mode_p): Define target hook.
gcc/testsuite/ChangeLog:
PR target/106733
* gcc.target/bpf/constant-calls.c: Rename to ...
* gcc.target/bpf/constant-calls-1.c: and modify to not expect
failure anymore.
* gcc.target/bpf/constant-calls-2.c: New test.
Diffstat (limited to 'gcc/config/bpf')
-rw-r--r-- | gcc/config/bpf/bpf.cc | 21 |
1 files changed, 20 insertions, 1 deletions
diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc index 6a0e3bb..7e37e08 100644 --- a/gcc/config/bpf/bpf.cc +++ b/gcc/config/bpf/bpf.cc @@ -659,12 +659,15 @@ bpf_address_base_p (rtx x, bool strict) target machine for a memory operand of mode MODE. */ static bool -bpf_legitimate_address_p (machine_mode mode ATTRIBUTE_UNUSED, +bpf_legitimate_address_p (machine_mode mode, rtx x, bool strict) { switch (GET_CODE (x)) { + case CONST_INT: + return (mode == FUNCTION_MODE); + case REG: return bpf_address_base_p (x, strict); @@ -1311,6 +1314,22 @@ bpf_core_walk (tree *tp, int *walk_subtrees, void *data) return NULL_TREE; } +/* Implement target hook small_register_classes_for_mode_p. */ + +static bool +bpf_small_register_classes_for_mode_p (machine_mode mode) +{ + if (TARGET_XBPF) + return 1; + else + /* Avoid putting function addresses in registers, as calling these + is not supported in eBPF. */ + return (mode != FUNCTION_MODE); +} + +#undef TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P +#define TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P \ + bpf_small_register_classes_for_mode_p /* Implement TARGET_RESOLVE_OVERLOADED_BUILTIN (see gccint manual section Target Macros::Misc.). |