[llvm] r227414 - [LPM] Try again to appease powerpc64 in its self host. I've been unable

Hal Finkel hfinkel at anl.gov
Thu Jan 29 08:13:21 PST 2015


----- Original Message -----
> From: "Ulrich Weigand" <Ulrich.Weigand at de.ibm.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Chandler Carruth" <chandlerc at gmail.com>, "Commit Messages and Patches for LLVM" <llvm-commits at cs.uiuc.edu>,
> "Rafael EspĂ­ndola" <rafael.espindola at gmail.com>, "Bill Schmidt" <wschmidt at linux.vnet.ibm.com>
> Sent: Thursday, January 29, 2015 9:17:56 AM
> Subject: Re: [llvm] r227414 - [LPM] Try again to appease powerpc64 in its self host. I've been unable
> 
> Hal Finkel <hfinkel at anl.gov> wrote on 29.01.2015 13:49:21:
> 
> > I was able to reproduce the problem with r227415 on my PPC64 P7
> > box,
> > and setting:
> >   CMAKE_EXE_LINKER_FLAGS:STRING=-Wl,--no-tls-get-addr-optimize -
> > Wl,--no-tls-optimize
> >   CMAKE_MODULE_LINKER_FLAGS:STRING=-Wl,--no-tls-get-addr-optimize -
> > Wl,--no-tls-optimize
> > made the problem go away. Given that the bug is actually in the
> > linker, I think this is really the proper solution. Can we add
> > these
> > to our build flags for PPC64 for now?
> 
> It's probably indeed the best to use the linker flag for now.
> 
> However, I think adding them to the LLVM build flags is the wrong
> place; there is nothing special about compiling the LLVM code base
> as such.  Rather, the problem is using clang/LLVM to compile *any*
> coding using general-/local-dynamics TLS variables.
> 
> So I think the flags should be added by the clang compiler driver
> whenever it invokes the linker on PowerPC.  (At least for now,
> and in 3.6.  They can be removed again once Bill has changed the
> code generation to again ensure use of r3 as expected by broken
> linkers ...)

Agreed. Can you please post a patch?

 -Hal

> 
> Bye,
> Ulrich
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory




More information about the llvm-commits mailing list