[llvm] r211040 - Fix illegal relocations in X86FastISel

[Eric Christopher]

Thanks!

-eric

On Mon, Jun 16, 2014 at 1:42 PM, Louis Gerbarg <lgg at apple.com> wrote:
> Per our discussions on IRC I committed a patch with improved comments
> explaining what is going on in case anyone ever has need to bring this into
> fast isel instead of just bailing since it is an edge case: r211052.
>
> On Jun 16, 2014, at 10:52 AM, Eric Christopher <echristo at gmail.com> wrote:
>
> On Mon, Jun 16, 2014 at 10:35 AM, Louis Gerbarg <lgg at apple.com> wrote:
>
> Author: louis
> Date: Mon Jun 16 12:35:40 2014
> New Revision: 211040
>
> URL: http://llvm.org/viewvc/llvm-project?rev=211040&view=rev
> Log:
> Fix illegal relocations in X86FastISel
>
> On x86_86  the lea instruction can only use a 32 bit immediate value. When
> the code is compiled statically the RIP register is not used, meaning the
> immediate is all that can be used for the relocation, which is not
> sufficient
> in the case of targets more than +/- 2GB away. This patch bails out of fast
> isel in those cases and reverts to DAG which does the right thing.
>
> Test case included.
>
>
> Some questions below:
>
>   // Materialize addresses with LEA instructions.
>   if (isa<GlobalValue>(C)) {
> +    //LEA can only handle 32 bit immediates
> +    if (TM.getRelocationModel() == Reloc::Static && Subtarget->is64Bit())
> +      return false;
> +
>
>
> Couldn't we lock down this check a bit more or handle the case?
>
> ==============================================================================
> --- llvm/trunk/test/DebugInfo/X86/debug-loc-asan.ll (original)
> +++ llvm/trunk/test/DebugInfo/X86/debug-loc-asan.ll Mon Jun 16 12:35:40 2014
> @@ -10,10 +10,10 @@
> ; with "clang++ -S -emit-llvm -fsanitize=address -O0 -g test.cc"
>
> ; First, argument variable "y" resides in %rdi:
> -; CHECK: DEBUG_VALUE: bar:y <- RDI
> +; CHECK: DEBUG_VALUE: bar:y <- RDX
>
>
> The comment says rdi, the code says rdx. :)
>
> Did you verify it's actually in rdx now? If so, could you update it.
>
>
> Also cleaned this comment up in r211052.
>
> Louis