[PATCH] D13977: [X86] Add elfiamcu triple support, and a workaround for PR3997

Michael Kuperstein via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 23 00:09:56 PDT 2015


mkuper added a comment.

In http://reviews.llvm.org/D13977#273248, @rnk wrote:

> It'd be nice if we come come up with a more general solution to PR3997. If we had a way to send arbitrary module-wide flags through to the backend like TargetTuple, then we'd go ahead and put mregparm=3 there. Obviously we don't, and we've been trying to move towards per-function attributes. So, we could conceivably slap an attribute like "libcall-regparms"=N on every function, and then, during markInRegArguments, look at that after checking the triple.
>
> What do you guys think?


My only objection to this is that it gives the impression that it's ok to mix different libcall-regparms functions in the same module. IIRC the main reasoning for relying mainly on per-function attributes is LTO - and I'm fairly sure this particular mix-and-match should never happen, regardless of LTO. Having said that, I don't think we currently have a better way to do this.

Also, given how long-standing the issue in PR3997 is, I'm somewhat reluctant (perhaps, scared) to fix it.
Is it reasonable to assume nobody is relying on the current ("broken/GCC-incompatible") behavior of -mregparm? And how much do we care about being backward compatible with that?


http://reviews.llvm.org/D13977





More information about the llvm-commits mailing list