[llvm-commits] [llvm] r170016 - /llvm/trunk/test/CodeGen/PowerPC/tls-ld-obj.ll

[Bill Schmidt]

On Wed, 2012-12-12 at 14:07 -0800, Chandler Carruth wrote:
> On Wed, Dec 12, 2012 at 12:29 PM, Bill Schmidt
> <wschmidt at linux.vnet.ibm.com> wrote:
>         Author: wschmidt
>         Date: Wed Dec 12 14:29:20 2012
>         New Revision: 170016
>         
>         URL: http://llvm.org/viewvc/llvm-project?rev=170016&view=rev
>         Log:
>         The ordering of two relocations on the same instruction is
>         apparently not
>         predictable when compiled on at least one non-PowerPC host.
>          Source of
>         nondeterminism not apparent.  Restrict the test to build on
>         PowerPC hosts
>         for now while looking into the issue further.
> 
> 
> Ow, and thanks for finding this!!! Please let folks know if we can
> help track this down. Non-determinism is scary.

Finally got some time to look at this.  The problem appears to be with
this, from ELFObjectWriter.cpp: WriteRelocationFragment():

  // Sort the relocation entries. Most targets just sort by r_offset,
but some
  // (e.g., MIPS) have additional constraints.
  TargetObjectWriter->sortRelocs(Asm, Relocs);

This ends up doing a qsort() based on the r_offset field, which IIRC is
nondeterministic when two entries have the same key.  I guess I'll have
to override sortRelocs for PPC.

>  
>         
>         Modified:
>             llvm/trunk/test/CodeGen/PowerPC/tls-ld-obj.ll
>         
>         Modified: llvm/trunk/test/CodeGen/PowerPC/tls-ld-obj.ll
>         URL:
>         http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/PowerPC/tls-ld-obj.ll?rev=170016&r1=170015&r2=170016&view=diff
>         ==============================================================================
>         --- llvm/trunk/test/CodeGen/PowerPC/tls-ld-obj.ll (original)
>         +++ llvm/trunk/test/CodeGen/PowerPC/tls-ld-obj.ll Wed Dec 12
>         14:29:20 2012
>         @@ -4,6 +4,10 @@
>          ; Test correct relocation generation for thread-local storage
>         using
>          ; the local dynamic model.
>         
>         +; Relocations 2 and 3 seem to come out in unpredictable order
>         on some
>         +; architectures, so restrict this for now.
>         +; REQUIRES: ppc64-registered-target
>         +
>          target datalayout =
>         "E-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f128:128:128-v128:128:128-n32:64"
>          target triple = "powerpc64-unknown-linux-gnu"
>         
>         @@ -17,9 +21,10 @@
>            ret i32 %0
>          }
>         
>         -; Verify generation of R_PPC64_GOT_TLSGD16_HA,
>         R_PPC64_GOT_TLSGD16_LO,
>         -; and R_PPC64_TLSGD for accessing external variable a, and
>         R_PPC64_REL24
>         -; for the call to __tls_get_addr.
>         +; Verify generation of R_PPC64_GOT_TLSLD16_HA,
>         R_PPC64_GOT_TLSLD16_LO,
>         +; R_PPC64_TLSLD, R_PPC64_DTPREL16_HA, and R_PPC64_DTPREL16_LO
>         for
>         +; accessing external variable a, and R_PPC64_REL24 for the
>         call to
>         +; __tls_get_addr.
>          ;
>          ; CHECK:       '.rela.text'
>          ; CHECK:       Relocation 0
>         
>         
>         _______________________________________________
>         llvm-commits mailing list
>         llvm-commits at cs.uiuc.edu
>         http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 
>