[llvm-commits] [PATCH] Use an alternate symbol for function-size calc
hfinkel at anl.gov
Fri Dec 30 08:41:00 PST 2011
On Fri, 2011-12-30 at 17:12 +0100, Joerg Sonnenberger wrote:
> On Fri, Dec 30, 2011 at 10:01:10AM -0600, Hal Finkel wrote:
> > On Fri, 2011-12-30 at 15:50 +0100, Joerg Sonnenberger wrote:
> > > On Thu, Dec 29, 2011 at 09:09:55PM -0500, Rafael Ávila de Espíndola wrote:
> > > > On 29/12/11 03:20 PM, Hal Finkel wrote:
> > > > > This small patch fixes a compatibility problem between the ppc linux asm
> > > > > printer and recent versions of binutils (as explained in the test case).
> > > > > With this patch, llvm's behavior will again match that of gcc. It
> > > > > touches CodeGen/AsmPrinter; please review.
> > > >
> > > > Do you know when this was changed in binutils? Maybe we should always
> > > > use the local symbol instead of making this a ppc only change.
> > >
> > > Or more importantly, why it was changed. There seems to be a plethora of
> > > questionable changes in binutils lately.
> > To be fair, the current behavior produces assembly like:
> > test1:
> > .quad .L.test1,.TOC. at tocbase
> > .previous
> > .L.test1:
> > ...
> > .Ltmp0:
> > .size test1, .Ltmp0-test1
> > so this is asking gas to produce a size constant by subtracting two
> > labels from different (sub)sections. Is that generally legal? Once I
> > realized what it was doing, I was surprised that it had ever worked.
> OK, this is a bit questionable. What's the purpose of the .previous
> again? Could we use the more modern .pushsection/.popsection instead?
> They are a bit less nasty in the backend...
My experience here is limited, so I'm not sure. Does the
".quad .L.test1,.TOC. at tocbase" induce an implied section change?
> I don't think there is a good reason for not just always creating the
> local label to avoid the difference.
I agree, this sounds like a good idea.
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-commits