Unable to parse data layout: `e-m:o-i64:64-i128:128-n32:64-S128-Fn32`

[langston-barrett]

I realize that the README does not say that LLVM 17 is supported, but I figured I'd put this here anyway.

unable to parse data layout: ``e-m:o-i64:64-i128:128-n32:64-S128-Fn32''
from:
	value symbol table
	MODULE_BLOCK
	Bitstream

Apple clang version 17.0.0 (clang-1700.0.13.3)
Target: arm64-apple-darwin24.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

test.zip

[langston-barrett]

I get the same thing with Clang 19 from Nix:

clang version 19.1.7
Target: aarch64-apple-darwin
Thread model: posix
InstalledDir: /nix/store/2rij3brrzn54mzd82hs496cqxdx82n2f-clang-19.1.7/bin

[RyanGlScott]

I think this is ultimately an llvm-pretty bug, since parseDataLayout (the function which ultimately is responsible for this failure) lives here in llvm-pretty.

[RyanGlScott]

My guess (from a quick reading of the LLVM Language Reference's data layout section) is that parseDataLayout is failing to parse the Fn32, which specifies the alignment for function pointers. The Language Reference has this to say:

F<type><abi>

This specifies the alignment for function pointers. The options for <type> are:

• i: The alignment of function pointers is independent of the alignment of functions, and is a multiple of <abi>.

• n: The alignment of function pointers is a multiple of the explicit alignment specified on the function, and is a multiple of <abi>.

We'd need to add a new constructor to LayoutSpec and update parseDataLayout accordingly.

[RyanGlScott]

Also, I don't think this is a new addition to LLVM's data layout syntax, since the documentation above has been present since at least LLVM 9.0. Moreover, I don't think this is specific to Apple Clang.

I'll relabel things accordingly.

[sauclovian-g]

I stepped on this again just now, and it would be great to get it fixed because it's pretty irritating.

[RyanGlScott]

I've pushed some proof-of-concept patches which (I believe) should resolve this:

• llvm-pretty: in this branch
• crucible: in this branch

Could you try loading an affected LLVM bitcode module (either using crux-llvm or by using the llvm-pretty-bc-parser API directly) to see if that fixes the issue? If so, we should land the patches above. It would also be nice to add a regression test in llvm-pretty-bc-parser.