[llvm-dev] Got stuck with PC-rel branching

Peter Bel via llvm-dev llvm-dev at lists.llvm.org
Thu Jan 19 10:21:21 PST 2017


Hi,

For the function call - yes, probably. But what about branching inside one
function (standard if-then for example)?

For example:
echo "int g() { int a = 1; if (a > 3) return 1; return 0; }" | clang -x c -
-o /tmp/a.o -c && objdump -d /tmp/a.o

Thanks,
Petr

On Thu, Jan 19, 2017 at 8:06 PM, Friedman, Eli <efriedma at codeaurora.org>
wrote:

> On 1/19/2017 9:11 AM, Peter Bel via llvm-dev wrote:
>
> Hi all,
>
>
>
> I'm trying to make an LLVM backend for the Adapteva's Epiphany E16 CPU
> (used in Parallella board), using CPU0 and some other backends as examples,
> and I've got stuck with branching.
>
> When I'm printing out asm, all branch labels are printed as they should
> be. But when I'm trying to generate obj file, I'm getting zeros instead of
> PC-related offset in all branch instructions.
>
> In short, what I'm doing:
>
> - Pattern (br bb:$addr) is selected using EpiphanyInstrInfo.td as
> BNONE32(ins jmptarget:$addr), Branch32 class
>
> - Branch32 class is defined in EpiphanyInstrFormats.td with bits<24> addr,
> which should go into bits{31-8} of the MC instruction. Those bits remain
> zeros after relaxation for some reason.
>
> - jmptarget operand has type OPERAND_PCREL, and uses EncoderMethod
> "getJumpTargetOpValue" defined in EpiphanyMCCodeEmitter. If this method
> gets MCExpr, it creates fixup, and I can see this fixup in debug.
>
> - Fixup is called fixup_Epiphany_PCREL24, and is defined in
> EpiphanyFixupKinds and EpiphanyAsmBackend, with FKF_IsPCRel flag.
>
>
>
> Can someone please tell me if I am missing something?
>
>
> Are you sure there's actually a problem?  On x86, for example:
>
> $ echo "int f(); int g() { return f(); }" | clang -x c - -o /tmp/a.o -c &&
> objdump -d /tmp/a.o
>
> /tmp/a.o:     file format elf64-x86-64
>
>
> Disassembly of section .text:
>
> 0000000000000000 <g>:
>    0:   55                      push   %rbp
>    1:   48 89 e5                mov    %rsp,%rbp
>    4:   b0 00                   mov    $0x0,%al
>    6:   e8 00 00 00 00          callq  b <g+0xb>
>    b:   5d                      pop    %rbp
>    c:   c3                      retq
>
> It looks like the call isn't calling the right function, but that's fine:
> it'll get fixed by the linker.
>
> -Eli
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170119/e6ff3f3e/attachment.html>


More information about the llvm-dev mailing list