Inconsistency in -march option between llc and clang


On AArch64 (ARM 64-Bit Platform), I see there is an inconsistency in the values accepted by -march option between clang and llc.

This is because Clang has a triple which provides the primary context
for interpreting -march. armv8a is a valid -march in both AArch32 and
AArch64 modes.

llc, on the other hand, uses -march as an abbreviated way to choose
the primary triple. It accepts a more limited set of options (arm,
thumb, arm64 or aarch64). It's not supposed to be a user-facing tool
though, so as long as there's a way to get the configuration you want
giving it a sophisticated interface isn't a priority (and arguably not
even desirable).

For llc, you probably want to use things like "-mattr=+v8.1a" to
specify architecture revisions (v8a is the default, since it's the
first 64-bit ARM version). And use either a full triple like
"-mtriple=aarch64-linux-gnu", or "-march=aarch64" if you don't care
what OS gets targeted (be careful there: tests vary subtly between iOS
and Linux and can break depending on the host machine if you're not




Just checking you're aware that armv8a does not (in ARM-speak) imply
aarch64. armv8a also includes changes to A32 and T32 such as e.g. the
Thumb2 IT instruction being deprecated unless applied only to a single
16 bit instruction (thus effectively reintroducing 32 bit predicated
instructions in T32)

So It's perfectly sensible to specify armv8a with things like -m32 or

Yes, that's right. I am aware of this. In fact AArch64 is just an execution "state" as defined by Documentation – Arm Developer

Also, Documentation – Arm Developer

But when the "CPU Architecture" as defined by the Main ID Register (MIDR), shows AArch64, then default is aarch64 and not -m32 not -mthumb, etc.

You're right that llc and clang do look inconsistent, of course.

I shall file it under bugs and assign it to myself.

I am OK with this explanation -- not to polish the user-interface of llc as it is not supposed to be a user-facing tool.

But this needs to be documented well. Package developers need to very well understand this, Today I see that llc is used quite a lot of places specially in system software development. For instance, POCL (Portable OpenCL) uses clang and llc both. But tries to use the same value for -march and fails.

I think there's an interest in making the interfaces similar, not identical.

But, as Tim said, Clang operates on "architecture independent" source
files, while llc operates on *platform specific* IR. So, having a
strong triple / arch command line options for llc makes no sense, as
you shouldn't be messing around those flags in llc anyway.

You can easily get the *wrong* result and not notice, so having a
broken interface stops you from doing silly things. For example,
compile to x86_64 IR, then use -march=aarch64. This is bound to create
all sorts of silent problems, especially if you silence the warnings.

I'm not advocating for breaking one thing to fix the other, though.
All I'm saying is that, teaching people to "use" llc's interface may
take them into a place they don't want to be, and there will be no
easy error checks. So, if you're going down the path of using llc
inside another tool, I strongly recommend you to patch up llc's arch
validation mechanism (IR data layout/triple vs. command line options)
first, to make sure warnings and errors are what they must be.