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

[Stepan Dyatkovskiy]

Hi Jiangning,
 > 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.
Yup. I spent a while before clearance about Fixups came to me too :-)
So, can we commit MCFixup?

-Stepan

Jiangning Liu wrote:
> 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
> <mailto: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 <mailto: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 <mailto:llvm-commits at cs.uiuc.edu>
>     http://lists.cs.uiuc.edu/__mailman/listinfo/llvm-commits
>     <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>
>
>
>
>
> --
> Thanks,
> -Jiangning