[llvm-dev] Lowering a reasonably complex struct seems to create over complex and invalid assembly fixups on some targets

carl-llvm-dev@petosoft.com via llvm-dev llvm-dev at lists.llvm.org
Sat Jul 14 03:47:16 PDT 2018


When I compile this LLVM IR….

@0 = private constant [19 x i8] c"V4main10Brightness\00", section "__TEXT,__swift3_typeref, regular, no_dead_strip"
@1 = private constant [9 x i8] c"Vs5UInt8\00", section "__TEXT,__swift3_typeref, regular, no_dead_strip"
@2 = private constant [18 x i8] c"currentBrightness\00", section "__TEXT,__swift3_reflstr, regular, no_dead_strip"
@_TMRfV4main10Brightness =
internal constant <{ i32, i16, i16, i32, i32, i32, i32 }>
    <{
        i32 trunc
        (i64 sub
        (
            i64 ptrtoint ([19 x i8]* @0 to i64),
            i64 ptrtoint (<{ i32, i16, i16, i32, i32, i32, i32 }>* @_TMRfV4main10Brightness to i64)
            )
        to i32),
        
        i16 0,
        i16 12,
        i32 1,
        i32 0,
        
        i32 trunc
        (i64 sub
        (i64 ptrtoint ([9 x i8]* @1 to i64),
        i64 add (i64 ptrtoint (<{ i32, i16, i16, i32, i32, i32, i32 }>* @_TMRfV4main10Brightness to i64),
            i64 16)
        ) to i32),
        i32 trunc
        (i64 sub
        (
        i64 ptrtoint ([18 x i8]* @2 to i64),
        i64 add
        (i64 ptrtoint (<{ i32, i16, i16, i32, i32, i32, i32 }>* @_TMRfV4main10Brightness to i64),
        i64 20)
        ) to i32)
        }>, section "__TEXT,__swift3_fieldmd, regular, no_dead_strip", align 4
…on a couple of targets, it seems to produce invalid MC graphs that then fail to compile.
My chosen platform is AVR but it looks like it probably produces strange fixups on MIPS too.
I was initially chatting to the AVR rust team about this but I’m not sure it’s an AVR only problem. I’d like some help with understanding why these fixups are being created.
When compiled on AVR, I get the error "LLVM ERROR: expected relocatable expression”.
If I compile to asm, I get these fixups…
llc -march=avr -mcpu=atmega328p cause-relocation-error.ll -filetype=obj -debug 2>&1|
grep unnamed_4
        Fixups:[<MCFixup Offset:0 Value:(__unnamed_4&65535)-((_TMRfV4main10Brightness&65535)+16) Kind:2>]>,
           (__unnamed_4, Index:0, ),
        Fixups:[<MCFixup Offset:0 Value:(__unnamed_4&65535)-((_TMRfV4main10Brightness&65535)+16) Kind:2>]>,
           (__unnamed_4, Index:0, ),
        Fixups:[<MCFixup Offset:0 Value:(__unnamed_4&65535)-((_TMRfV4main10Brightness&65535)+16) Kind:2>]>,
           (__unnamed_4, Index:0, ),
The output .s file in assembly:
.text
 .file "min-3.ll"

 .type __unnamed_3, at object     ; @2
 .section "__TEXT,__swift3_typeref, regular, no_dead_strip","a", at progbits
 .p2align 4
__unnamed_3:
 .asciz "V4main10Brightness"
 .size __unnamed_3, 19

 .type __unnamed_4, at object     ; @3
__unnamed_4:
 .asciz "Vs5UInt8"
 .size __unnamed_4, 9

 .type __unnamed_5, at object     ; @4
 .section "__TEXT,__swift3_reflstr, regular, no_dead_strip","a", at progbits
 .p2align 4
__unnamed_5:
 .asciz "currentBrightness"
 .size __unnamed_5, 18

 .type _TMRfV4main10Brightness, at object ; @_TMRfV4main10Brightness
 .section "__TEXT,__swift3_fieldmd, regular, no_dead_strip","a", at progbits
 .p2align 2
_TMRfV4main10Brightness:
 .long __unnamed_3-_TMRfV4main10Brightness
 .short 0                       ; 0x0
 .short 12                      ; 0xc
 .long 1                       ; 0x1
 .long 0                       ; 0x0
 .long (__unnamed_4&65535)-((_TMRfV4main10Brightness&65535)+16)
 .long (__unnamed_5&65535)-((_TMRfV4main10Brightness&65535)+20)
 .size _TMRfV4main10Brightness, 24
If I try to compile this file with llvm-mc it doesn’t work, with much the same error.
Debugging with lldb, I found that in MCAssembler::evaluateFixup it calls MCExpr::evaluateAsRelocatableImpl and that returns false because it doesn’t accept a fixup like __unnamed_4&65535, binary MC expressions only seem to allow combining symbols using + or - (using EvaluateSymbolicAdd), not and, or, div, mul… etc.
On x86 the assembly output is simpler:
llc cause-relocation-error.ll -filetype=obj -debug 2>&1|
grep unnamed_4                                              
        Fixups:[<MCFixup Offset:0 Value:.L__unnamed_4-(_TMRfV4main10Brightness+16) Kind:2>]>
,
           (.L__unnamed_4, Index:0, ),
        Fixups:[<MCFixup Offset:0 Value:.L__unnamed_4-(_TMRfV4main10Brightness+16) Kind:2>]>
,
           (.L__unnamed_4, Index:0, ),
        Fixups:[<MCFixup Offset:0 Value:.L__unnamed_4-(_TMRfV4main10Brightness+16) Kind:2>]>
,
           (.L__unnamed_4, Index:0, ),
Which compiles fine because the fixup combines symbols using only + and -, not &.
On MIPS, again the & operator is being put into expressions that end up in fixups.
llc -march=mips cause-relocation-error.ll -filetype=obj -debug 2>&1|
grep unnamed_4                                 
        Fixups:[<MCFixup Offset:0 Value:(($__unnamed_4)&4294967295)-((_TMRfV4main10Brightness&4294967295)+16) Kind:2>]>,
           ($__unnamed_4, Index:0, ),
        Fixups:[<MCFixup Offset:0 Value:(($__unnamed_4)&4294967295)-((_TMRfV4main10Brightness&4294967295)+16) Kind:2>]>,
           ($__unnamed_4, Index:0, ),
        Fixups:[<MCFixup Offset:0 Value:(($__unnamed_4)&4294967295)-((_TMRfV4main10Brightness&4294967295)+16) Kind:2>]>,
           ($__unnamed_4, Index:0, ),
Which I don’t think would compile.
AVR is an experimental target but I think MIPS is mature?  So I’m trying to get to the bottom of how LLVM is lowering to these expressions in fixups, when they cannot be evaluated by the MC layer?
Can anyone give any advice?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180714/668cb9e0/attachment.html>


More information about the llvm-dev mailing list