Fix size and offset computations of types

[ThomasHaas]

This PR improves computations of types sizes, alignments, and offsets.
Previously, we had wrong computations in many cases, however, it only rarely lead to issues in benchmarks that made use of offset_of compiler primitives or similar ways to compute pointer offsets without GEP.
As a result, issue #586 should also be resolved.

[hernanponcedeleon]

I could not spot anything fundamentally wrong, but there are way too many computations going on.

Can you add some basic tests with a structure where the compiler adds some padding. Maybe we can even have a second structure will the same members, but add __attribute__((packed)); to avoid the padding.

[ThomasHaas]

I could not spot anything fundamentally wrong, but there are way too many computations going on.

Can you add some basic tests with a structure where the compiler adds some padding.

All LLVM IR structs are padded by default but you won't see the padding in the IR expliclity. So in fact, many non-trivial benchmarks have padded structs and our internal type size computation was almost always wrong (it was always missing trailing padding). The difficult part is making those tests fail, because wrong size/offset computations simply do not matter unless you have offsetof somewhere. I will see what I can do.

Maybe we can even have a second structure will the same members, but add __attribute__((packed)); to avoid the padding.

IIRC, adding __attribute__((packed)) will result in IR code that we cannot handle, because the LLVM IR declaration of the struct uses extra brackets <...> (LangRef). We might parse the code, but we certainly ignore the packedness!

[ThomasHaas]

I added a test that breaks on development (if run without opt passes) but runs correctly on this PR.

[hernanponcedeleon]

I added a test that breaks on development (if run without opt passes) but runs correctly on this PR.

Great. Thanks!