[LLVMdev] C int type for 48bits cpu
t.p.northover at gmail.com
Thu Sep 5 02:10:47 PDT 2013
> As you can see, i48 was a perfectly valid LLVM type.
> Without having written a backend, I'd imagine you specify what
> types are legal and then either generic code or target-dependent
> code is going to legalize the type. In my example, I imagine the
> i48 was legalized to an i64 which is legal for my target architecture.
Only certain types can be legal in a normal backend, everything gets
mapped to the MVT enum. Currently the only backend integer types
allowed are i1, i8, i16, i32, i64 and i128. To support i48 properly
you'd have to add it to that list of types. Running a "grep -r i128"
should give you a very rough indication of what's involved. Less than
I expected, actually.
There are three possible outcomes after doing that:
1. Everything works perfectly.
2. Code expects power-of-2 widths and breaks when your backend starts
feeding it i48 (in particular it may expect to be able to reach a
legal type by doubling or halving the width repeatedly)
3. Code expects power-of-2 widths and every existing backend breaks
horribly because of this new i48.
I'd hope for 2, but fear 3.
Clang should be flexible about what int maps to, though. MSP430, for
example, uses i16. Of course, you shouldn't be surprised if there are
extra bugs to deal with there too.
More information about the llvm-dev