[PATCH] D25324: [ELF] - Check that section alignment is a power of 2.

[Rui Ueyama via llvm-commits]

We used to represent alignments both in 2^n and log2, and I streamlined it
by using 2^n consistently because it was confusing. So I'm inclined not to
go back to that state unless you show saving a few bits is worth doing.

As to the division, I think alignTo in MathExtras.h is too powerful that it
can handle alignment of non-power-of-2. It can take any number as an
alignment. Do we really need it? I'm wondering if we can replace the
implementation with this

  inline uint64_t alignTo(uint64_t Value, uint64_t Align, uint64_t Skew =
0) {
    assert(Align != 0 && "Align can't be 0.");
    assert(!isPowerOf2_64(Align) && "Align must be a power of 2.");
    // return (Value + Align - 1 - Skew) / Align * Align + Skew;
    return ((Value - Skew + Align - 1) & -Align) + Skew;
  }

On Thu, Oct 6, 2016 at 11:31 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> Since we are talking alignment:
>
> We use alignTo quite often and that causes a divq. That is
> surprisingly fast on modern cpus, but I wonder if we should normalize
> the alignment to its log2. That would also have the advantage of
> requiring far fewer bits to store.
>
> If we do that it should definitely be another patch.
>
> Cheers,
> Rafael
>
>
> On 6 October 2016 at 14:25, Rui Ueyama <ruiu at google.com> wrote:
> > ruiu added inline comments.
> >
> >
> >> InputSection.cpp:48
> >>    // no alignment constraits.
> >> -  if (Header->sh_addralign > UINT32_MAX)
> >> -    fatal(getFilename(File) + ": section sh_addralign is too large");
> >> +  if (Header->sh_addralign > UINT32_MAX ||
> >> +      (Header->sh_addralign && !isPowerOf2_32(Header->sh_addralign)))
> >
> > Also, please leave a comment here to say that we reject object files
> having insanely large alignment requirements and may want to relax this
> limitation in the future.
> >
> > binutils-ish tools have incredible long lifetime -- GNU ld has been used
> for decades now for example. We want to leave a hint why we are doing this,
> so that people who look at this code 10 years later won't have to wonder
> why we reject 4GB-aligned sections when they are creating 10 terabyte
> executable.
> >
> > https://reviews.llvm.org/D25324
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161006/2e3eeb10/attachment.html>