What to do about alignment of ELF objects

Sean Silva chisophugis at gmail.com
Thu Apr 23 14:44:00 PDT 2015


On Thu, Apr 23, 2015 at 2:34 PM, Rafael EspĂ­ndola <
rafael.espindola at gmail.com> wrote:

> On 23 April 2015 at 17:22, Sean Silva <chisophugis at gmail.com> wrote:
> >
> >
> > On Thu, Apr 23, 2015 at 12:12 PM, Rafael EspĂ­ndola
> > <rafael.espindola at gmail.com> wrote:
> >>
> >> On 23 April 2015 at 14:17, Rui Ueyama <ruiu at google.com> wrote:
> >> > I think the patch for LLVM looks okay, but not sure for the other one.
> >> >
> >> > Your patch makes the linker to not be able to handle archive files
> >> > containing unaligned objects, or just makes it slower? If you
> cross-link
> >> > an
> >> > executable for machines generous for unaligned accesses, say x86, on
> >> > not-so-generous machines, PowerPC for example, does it link fine?
> >>
> >> Not difference on X86 (we avoid the copy).
> >
> >
> > This has the potential to radically change LLD's physical/virtual memory
> > usage characteristics depending on LLVM_IS_UNALIGNED_ACCESS_FAST (LIUAF)
> > along with total memory traffic profile and disk access patterns. For
> > example, this patch causes the entire file to be faulted in and read up
> > front on !LIUAF whereas the file might be faulted and touched on disk
> > sparsely and/or in a random order when LIUAF. Realistically most
> > benchmarking and optimization work is going to happen on x86 and so
> > performance on !LIUAF is likely to "bit rot" (we currently don't have any
> > type of performance CI to avoid this; this is on my TODO list).
> >
> > Have you tried copying the buffers on x86? Also, if you make sure that
> the
> > incoming archives are aligned so you can avoid the copy on ppc, how much
> > faster does it get? I.e. does (time saved from your patch on ppc)  ==
> (time
> > copying buffers with your patch on ppc) + (time saved if we use aligned
> > archives and avoid the copy with your patch (for testing purposes))?
> >
> > Can you dig in a bit deeper and figure out where this speedup is coming
> > from? As it stands right now, this patch seems like a very opportunistic
> > "seems to work on my machine" speedup.
>
> At this I don't think ti is worth it. We don't support powerpc, which
> is why I had to do a cross linking to benchmark it.
>

Could you at least test if eagerly faulting in/loading archives speeds up
x86?


>
> The main issue is deleting a bunch of complicated dead code (on x86)
>

Ok, that I agree with. However it seems like the ownership issue would be
completely sidestepped by just using alignment 2 everywhere. It might not
be any slower.

-- Sean Silva


> that just slows down other architectures.
>
> For what it is worth, gold copies data when the buffer is not
> sufficiently aligned, so this is know to work.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150423/ab542cdb/attachment.html>


More information about the llvm-commits mailing list