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

[Stepan Dyatkovskiy]

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
>