<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 14, 2015 at 6:01 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>> The object we are building is aligned, but the type doesn't know that.<br>
><br>
><br>
> What do you mean? Are you suggesting that we should use aligned_ulittle32_t<br>
> instead of ulittle32_t to avoid byte swapping overhead in cross-linking use<br>
> case?<br>
<br>
</span>No, we have to use the final endian in here since we are writing<br>
directly to the output file.<br>
<br>
But Elf_Wold is defined as<br>
<br>
 typedef support::detail::packed_endian_specific_integral<<br>
      uint32_t, target_endianness, 2> Elf_Word;<br>
<br>
So the type only knows that it is aligned to 2. It is not important<br>
for X86_64 since the generated instructions are the same and at<br>
runtime the pointer will be aligned anyway. For architectures with<br>
strict alignment we will be generating less efficient code, but then<br>
again we will have to benchmark a few alternatives in here in the<br>
future. For now it is OK to just keep the simpler code (i.e.: your<br>
patch).</blockquote><div><br></div><div>Ah, got it. I somehow thought that Elf_Word was a simple typedef to uint32_t, which is not true.</div></div><br></div></div>