[llvm] r204901 - Rejected r204899 and r204900 due to remaining test failures on cmake-llvm-x86_64-linux buildbot.

[Jiangning Liu]

Hi Stepan,

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.

Thanks,
-Jiangning



2014-03-28 14:24 GMT+08:00 Stepan Dyatkovskiy <stpworld at narod.ru>:

> Hi all,
> Renato,
> If it will not evaluated, it *will* fail with "expected relocatable
> expression" message.
>
> Try next:
>     .text
>     cmp r2, #(l2 - doesntExist) >> 2
> l1:
> l2:
>
>
> > 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
> expression");
>
> 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?
>
> -Stepan.
>
>
> Renato Golin wrote:
>
>> On 27 March 2014 21:00, Rafael Espíndola <rafael.espindola at gmail.com>
>> wrote:
>>
>>> 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.
>>
>> cheers,
>> --renato
>>
>>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>



-- 
Thanks,
-Jiangning
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140328/32b58438/attachment.html>