[lld] r250297 - [ELF2][mips] Support both big and little endian MIPS 32-bit targets

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 14 13:46:01 PDT 2015


On Wed, Oct 14, 2015 at 1:43 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
> > From: "Rui Ueyama" <ruiu at google.com>
> > To: "Rafael EspĂ­ndola" <rafael.espindola at gmail.com>
> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "llvm-commits" <
> llvm-commits at lists.llvm.org>
> > Sent: Wednesday, October 14, 2015 3:39:28 PM
> > Subject: Re: [lld] r250297 - [ELF2][mips] Support both big and little
> endian MIPS 32-bit targets
> >
> >
> > On Wed, Oct 14, 2015 at 1:25 PM, Rafael EspĂ­ndola <
> > llvm-commits at lists.llvm.org > wrote:
> >
> >
> > > One solution would be to define:
> > >
> > > template <endianness endian>
> > > inline uint32_t read32(const void *p) { return *(const
> > > detail::packed_endian_specific_integral<uint32_t, endian,
> > > unaligned> *) p; }
> > >
> > > and similar for write32, and implement Endian-independent things in
> > > terms of those.
> >
> > LGTM :-)
> >
> >
> > It doesn't look good to me. It looks more intricate than necessary. I
> > really prefer the current code over the suggested one.
>
> I would not put that template code into lld, it would belong in the
> support header. Honestly, generic operations (add32be, etc.) should be
> there too. This way the code in lld (and any other user) can be simpler,
> not more complicated.
>

That does make sense (and I also agree that addX should be moved from LLD
to LLVM).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151014/0be9d97a/attachment.html>


More information about the llvm-commits mailing list