On Wed, May 6, 2009 at 5:46 PM, Richard Earnshaw <rearn...@arm.com> wrote: > On Wed, 2009-05-06 at 17:44 +0200, Michael Matz wrote: >> Hi, >> >> On Wed, 6 May 2009, Ramana Radhakrishnan wrote: >> >> > >>> The slush that I requested last week has been lifted. However, I >> > >>> have asked for relative calm until the cond-optab branch has been >> > >>> merged to mainline, which will hopefully occur on Friday, May 8th. >> > >> >> > >> As of this morning (UK), native bootstrap on ARM is still broken. >> > > >> > > Is this PR 39978? >> > >> > I see what's been reported at >> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40031#c2 on gcc55 which appears >> > to be the same crash as what Julian's been seeing with >> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929#c12. >> >> As written by Andrew Pinski already, you'll need a different method of >> emitting the load of the PIC register. The ARM backend tries to emit that >> load as soon as it sees the PIC register being used (which is a slightly >> odd method as it magically emits instructions at a place unrelated to the >> instruction that currently are supposed to be emitted). >> >> With expand from SSA this happens earlier than before, in fact so early >> that you don't have any basic block in RTL yet. All are still in gimple >> form. That's why the emission of RTL insns after the function entry is >> not going to work. That's only possible if everything is transformed >> already. >> >> The easiest solution would be to just make a note that you need the PIC >> register and then, when expanding the prologue emit the necessary >> instructions. IMO that makes sense as PIC register setup usually is >> something the prologue does, like all the other register setups necessary. >> > > That won't work because the PIC register on ARM is a pseudo, so > generating it during prologue generation is too late. It needs to exist > before data flow analysis starts on the RTL.
So you can generate it unconditionally and let DCE remove it if it turns out not necessary? Richard.
