[PATCH] D76587: [BPF] support 128bit int explicitly in layout spec

Yonghong Song via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sun Mar 22 23:57:54 PDT 2020


yonghong-song created this revision.
yonghong-song added a reviewer: ast.
Herald added subscribers: cfe-commits, danielkiss, hiraditya, kristof.beyls.
Herald added a project: clang.

Currently, bpf does not specify 128bit alignment in its 
layout spec. So for a structure like

  struct ipv6_key_t {
    unsigned pid;
    unsigned __int128 saddr;
    unsigned short lport;
  };  

clang will generate IR type

  %struct.ipv6_key_t = type { i32, [12 x i8], i128, i16, [14 x i8] }

Additional padding is to ensure later IR->MIR can generate correct
stack layout with target layout spec.

But it is common practice for a tracing program to be
first compiled with target flag (e.g., x86_64 or aarch64) through
clang to generate IR and then go through llc to generate bpf 
byte code. Tracing program often refers to kernel internal
data structures which needs to be compiled with non-bpf target.

But such a compilation model may cause a problem on aarch64.
The bcc issue https://github.com/iovisor/bcc/issues/2827
reported such a problem.

For the above structure, since aarch64 has "i128:128" in its 
layout string, the generated IR will have

  %struct.ipv6_key_t = type { i32, i128, i16 }

Since bpf does not have "i128:128" in its spec string,
the selectionDAG assumes alignment 8 for i128 and 
computes the stack storage size for the above is 32 bytes,
which leads incorrect code later.

The x86_64 does not have this issue as it does not have
"i128:128" in its layout spec as it does permits i128 to
be alignmented at 8 bytes at stack. Its IR type looks like

  %struct.ipv6_key_t = type { i32, [12 x i8], i128, i16, [14 x i8] }

The fix here is add i128 support in layout spec, the same as
aarch64. The only downside is we may have less optimal stack
allocation in certain cases since we require 16byte alignment
for i128 instead of 8. But this is probably fine as i128 is
not used widely and in most cases users should already
have proper alignment.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D76587

Files:
  clang/lib/Basic/Targets/BPF.h
  clang/test/CodeGen/target-data.c
  llvm/lib/Target/BPF/BPFTargetMachine.cpp
  llvm/test/CodeGen/BPF/i128.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D76587.251948.patch
Type: text/x-patch
Size: 5202 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20200323/7fe77622/attachment-0001.bin>


More information about the cfe-commits mailing list