[llvm-dev] Alignment Member Functions should be Virtual

[Hiroyuki Chishiro via llvm-dev]

Dear Tim,

Thank you for your reply.

However, multiple aligned loads (such as 8-bit LB and/or 16-bit LH) to
access data have more time overhead compared to single aligned load
(such as 32-bit LW).
Therefore, my backend still uses 32-bit LW and both arrays of char and
short are 32-bit aligned regardless of more memory overhead (in many
cases).
If any problems occur, I will report them in this ML.

Sincerely,
Hiroyuki Chishiro


2018-05-03 16:19 GMT+09:00 Tim Northover <t.p.northover at gmail.com>:
> On 3 May 2018 at 03:23, Hiroyuki Chishiro via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> However, aligned memory access instructions (such as 32-bit LW) are
>> used in this case, and hence my compiler cannot correctly access char
>> string written in C.
>
> This hardware situation was reasonably common in the past, but code
> still accessed objects not aligned to 32-bits. The compiler just had
> to use multiple aligned loads to access data crossing a word boundary
> and combine the data.
>
> You'll probably find that path simpler than inventing a pathological C
> dialect. As Eli said, changing getCharAlign is likely to have huge
> knock-on consequences that the rest of Clang just isn't ready for.
>
> Cheers.
>
> Tim.



-- 
Hiroyuki Chishiro <chishiro at pf.is.s.u-tokyo.ac.jp>
The University of Tokyo