So, I remember back when I implemented the MCU ABI rnk and I discussed this, and didn't really reach a definitive conclusion.
This would make -mregparm behavior match GCC, but would be an ABI break for clang.
You may want to surface this on llvm-dev, and check that doesn't come as a surprise to anyone.
Another issue is that we need to serialize this as part of the IR for the function.
Since we don't use inreg attributes, it needs to either be a part of the calling convention (although we currently have no way to parametrize the CC, I think), or a function attribute.
I'm not sure. It basically comes down to - do we want to ever be able to combine (say, link) -mregparm code with non-mregparm code.
For the MCU this was a non-issue, because the answer is always no.
I'd like this to be conditional on NumRegisterParameters being non-zero, so that it doesn't pollute the vast majority of modules that don't use -mregparm. I think you will get the right LTO diagnostic behavior if you use llvm::Module::Require instead of Error here.
I think this can be removed if the module flag is made conditional.
My understanding is that Require only checks the post-linking values, so we'd not error when linking regparm 0 with regparm N.
That said, it'd be easy enough to restrict emitting the module flag to target that actually depend on it, i.e. X86-32. That would get us 90% of the way.
No intention of any major work intended... just moved the code (locally) to Release and regression tests were still passing.
I must be missing something - isn't the module flag is used in X86ISelLowering which is called after CodeGenModule::Release() is done?