r228253 - [PowerPC] Revert workaround for TLS linker bug
Bill Schmidt
wschmidt at linux.vnet.ibm.com
Thu Feb 5 17:19:21 PST 2015
On Thu, 2015-02-05 at 19:13 -0600, Bill Schmidt wrote:
> On Thu, 2015-02-05 at 18:52 -0600, Bill Schmidt wrote:
> > On Wed, 2015-02-04 at 18:30 -0800, Chandler Carruth wrote:
> > >
> > > On Wed, Feb 4, 2015 at 5:12 PM, Bill Schmidt
> > > <wschmidt at linux.vnet.ibm.com> wrote:
> > > Author: wschmidt
> > > Date: Wed Feb 4 19:12:24 2015
> > > New Revision: 228253
> > >
> > > URL: http://llvm.org/viewvc/llvm-project?rev=228253&view=rev
> > > Log:
> > > [PowerPC] Revert workaround for TLS linker bug
> > >
> > > In r227480, Ulrich Weigand introduced a workaround for a
> > > linker
> > > optimization bug that can create mis-optimized code for
> > > accesses to
> > > general-dynamic or local-dynamic TLS variables. The linker
> > > optimization bug only occurred for Clang/LLVM because of some
> > > inefficient code being generated for these TLS accesses. I
> > > have
> > > recently corrected LLVM to produce the efficient code sequence
> > > expected by the linkers, so this workaround is no longer
> > > needed.
> > > Therefore this patch reverts r227480.
> > >
> > > I've tested that the previous bootstrap failure no longer
> > > occurs with
> > > the workaround reverted.
> > >
> > > This is awesome Bill, thanks again for tackling all of this.
> >
> > Well, unfortunately it isn't going to stick. :(
> >
> > A bootstrap with -O3 still fails, and there is a further, different, and
> > more horrible linker optimization error to blame. I'm going to
> > re-disable the linker optimizations for now. I'm unwilling to handcuff
> > the compiler as much as would be required to let the linker optimization
> > operate in its present state.
>
> Correction: Still too soon to blame the linker here. My eyes were
> playing tricks on me. Will take a fresh look at the cause of the
> bootstrap error in the morning.
And as soon as I press Send, I see it. I was looking at the wrong
destructor this time.
Essentially what happens is this: I have a new pass that forces a
register copy of the __tls_get_call parameter into GPR3. In this case
RA is apparently unable to coalesce the copy away, which leaves the addi
targeting a non-GPR3 register again. So the known linker optimization
bug kicks in.
I will have to require def-use chains for the new pass so that I can
perform direct operand replacement instead of using register copies.
Will have a look at this tomorrow.
Bill
>
> Bill
>
> >
> > Details to follow.
> >
> > Bill
>
More information about the cfe-commits
mailing list