[llvm] r204901 - Rejected r204899 and r204900 due to remaining test failures on cmake-llvm-x86_64-linux buildbot.
liujiangning1 at gmail.com
Fri Mar 28 00:36:12 PDT 2014
I see what Fixup is now, and thanks for your explanation!
The solution sounds reasonable to me, and it is like a lazy-evaluation
after knowing the layout. I didn't realize there is such a stage.
2014-03-28 14:24 GMT+08:00 Stepan Dyatkovskiy <stpworld at narod.ru>:
> Hi all,
> If it will not evaluated, it *will* fail with "expected relocatable
> expression" message.
> Try next:
> cmp r2, #(l2 - doesntExist) >> 2
> > But we still need more examples as tests, just to make sure we
> > evaluate what's possible and err where it's not. I don't have a list,
> > unfortunately, bu tI know Saleem does, this is why I asked him.
> Couldn't we add them as additional commits?
> Below is my small research of how it works.
> Fixup's technique has been introduced for cases when you are not able to
> evaluate (resolve) some symbols, and thus not able to encode instruction
> properly. In this case you leave a gap in output code, and create an
> MCFixup instance with location of this gap.
> Then when encoding stage is finished, we start to resolve collection of
> MCFixup instances (see MCAssembler::Finish).
> As Rafael mentioned, MCAssembler::handleFixup is called. This method
> invokes evaluateFixup, and if it fails it puts relocation.
> evuluateFixup though, first, once again tries to fold expression via
> Fixup.getValue()->EvaluateAsRelocatable call. On this stage this method
> *always* has layout, so we always able to evaluate expressions. And if it
> failed to evaluate it, it emits error:
> if (!Fixup.getValue()->EvaluateAsRelocatable(Target, &Layout))
> getContext().FatalError(Fixup.getLoc(), "expected relocatable
> Else, if it managed to evaluate fixup, but it is still not absolute, it
> will put relocatable record.
> So I think, we can add MCFixup for now, then commit additional tests. And
> meanwhile I could switch to PR18929.
> What do you think, guys?
> Renato Golin wrote:
>> On 27 March 2014 21:00, Rafael Espíndola <rafael.espindola at gmail.com>
>>> That is what a fixup is :-)
>> Right. I used the term "fixup" before in the context of relocations,
>> and I thought the MC layer was just being smart to fold them later,
>> but there was no guarantee that it would happen. If at the final
>> emission the expression cannot be resolved, would that incur in an
>> error? If so, I think this is the right solution after all.
>> But we still need more examples as tests, just to make sure we
>> evaluate what's possible and err where it's not. I don't have a list,
>> unfortunately, bu tI know Saleem does, this is why I asked him.
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits