[llvm-bugs] [Bug 33599] New: BPF target: relocation records generated for calculations on constants

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=33599

            Bug ID: 33599
           Summary: BPF target: relocation records generated for
                    calculations on constants
           Product: new-bugs
           Version: 3.8
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: daniel at iogearbox.net
                CC: llvm-bugs at lists.llvm.org

cilium bug id: https://github.com/cilium/cilium/issues/1033

llc --version
llc: /lib64/libtinfo.so.5: no version information available (required by llc)
LLVM (http://llvm.org/):
  LLVM version 3.8.1
  Optimized build.
  Default target: x86_64-unknown-linux-gnu
  Host CPU: skylake

  Registered Targets:
[...]
    bpf        - BPF (host endian)
    bpfeb      - BPF (big endian)
    bpfel      - BPF (little endian)
[...]

No issue with following code:

static inline struct endpoint_info *__inline__ lookup_ip4_endpoint(struct iphdr
*ip4)
{
        struct endpoint_key key = { };
        key.ip4 = bpf_ntohl(42);
        return map_lookup_elem(&cilium_lxc, &key);
}

Issue with that one:

static inline struct endpoint_info *__inline__ lookup_ip4_endpoint(struct iphdr
*ip4)
{
        struct endpoint_key key = {
                .ip4 = bpf_ntohl(42);
        };

        return map_lookup_elem(&cilium_lxc, &key);
}

bpf_ntohl() implementation in both cases is at:

https://github.com/cilium/cilium/blob/master/bpf/lib/utils.h

LLVM generates an invalid reloc entry from BPF backend for the problematic
lookup_ip4_endpoint(), but it (rightfully) doesn't generate an entry for the
other one.

More details from asm:

[...]
# BB#154:
        std     -136(r10), r5
        ld_64   r1, <MCOperand Expr:(.Llookup_ip4_endpoint.key)>
        ldw     r2, 0(r1)
        ldw     r1, 4(r1)
        slli    r1, 32
        or      r1, r2
        std     -56(r10), r1
        std     -64(r10), r1
        mov     r2, r10
        addi    r2, -64
        ld_64   r1, <MCOperand Expr:(cilium_lxc)>
        call    1
        jeqi    r0, 0 goto LBB5_305
[...]
        .section        .rodata.cst16,"aM", at progbits,16
        .align  4                       # @lookup_ip4_endpoint.key
.Llookup_ip4_endpoint.key:
        .long   704643072               # 0x2a000000
        .zero   12

I would also have though that given this is all ops based on constants, that
LLVM optimizes all of this away and just performs the load of the final
constant.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170626/69743176/attachment.html>