Displaying 4 results from an estimated 4 matches for "evaluatefixup".
2011 Oct 10
1
[LLVMdev] Adding fixups and relocations late in code generation
...>
I'm not sure I follow. Wouldn't that still require a relocation from the start of the section?
> I also get a relocation request even though the label should be
> resolved.
>
The logic for which cases are considered resolved and which require relocations is in MCAssembler::EvaluateFixup(). It's currently not factored all that well, with some target-specific knowledge embedded in the generic code. It's entirely possible we need to create a target hook there to handle any special cases.
2011 Oct 10
0
[LLVMdev] Adding fixups and relocations late in code generation
...ying to not
> hack the code.
>
> I how exactly does one set an expression to be PC relative and if the
> compiler can resolve it, not produce a relocation?
>
Fixups are created for all expressions that may need a relocation. The MC layer evaluates them as best it can (MCAssembler::EvaluateFixup()) and calls the target hook RecordRelocation() if it cannot evaluate it directly and needs a relocation in the object file.
> In our case, the backend produces an expression for the branch which is
> the target label. I make a call from the .td for the branch instruction
> which calls a...
2011 Oct 10
2
[LLVMdev] Adding fixups and relocations late in code generation
Gang,
I'm tasked with direct object generation for Mips and am trying to not
hack the code.
I how exactly does one set an expression to be PC relative and if the
compiler can resolve it, not produce a relocation?
In our case, the backend produces an expression for the branch which is
the target label. I make a call from the .td for the branch instruction
which calls a routine in
2018 Jul 14
2
Lowering a reasonably complex struct seems to create over complex and invalid assembly fixups on some targets
...ed_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...