[PATCH] D57335: [IR] Don't assume all functions are 4 byte aligned

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

I've thought about it a bit more, and maybe specifying it in the datalayout is appropriate: the representation of function pointers is a fundamental property of the target/ABI.  I mean, it's not really that important in most cases... if you conservatively treat all function pointers as completely opaque, you'll usually get reasonable optimization, but it's still a fundamental property of a core IR type.

That said, I think the suggested datalayout modification isn't complete.  I think we need two possible specifications:

`F<bitwidth>`: The alignment of function pointers is independent of the alignment of functions, and is at least `<bitwidth>`.  ARM with Thumb uses `F8`, PPC use `F32`/`F64` for 32/64-bit targets, MIPS with microMIPS uses `F8`.
`f<bitwidth>`: The alignment of function pointers is greater than or equal to the explicit alignment specified on the function, and is at least `<bitwidth>`.  Used for other targets; x86 uses `f8`, aarch64 uses `f32`, etc.

There's an argument for using a target hook instead: in some cases, we can tell more about a specific function in some cases, so we want target hook anyway.  For example, on ARM, if a function uses an attribute to mark it as an ARM-mode function, the alignment is at least 32 bits; there's no way to specify that in the datalayout.  And if we have the target hook, very little code would end up querying the datalayout, so there's hardly any point.  (IIRC Chandler actually tried to write some code involving aligned function pointers for LLVM at one point, but it failed because we don't have that target hook.)


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57335/new/

https://reviews.llvm.org/D57335