r216662 - [ARM] Change default ABI for AArch32 to be "aapcs" (was "apcs-gnu")

Eric Christopher echristo at gmail.com
Wed Dec 10 11:46:48 PST 2014


On Wed Dec 10 2014 at 7:31:37 AM Renato Golin <renato.golin at linaro.org>
wrote:

> On 9 December 2014 at 21:55, Eric Christopher <echristo at gmail.com> wrote:
> > Ping? Do you have a reason for this change? Basically it means a lot of
> > updating the back end if we want them to agree for no good reason so I'm
> of
> > mind to revert this.
>
> Hi Eric,
>
> Is this causing any trouble?
>

So a bit. I'm trying to unify the code and as I said earlier, it makes the
default ABI different between the front end and backend.


>
> IIUC, this change will only have an effect when no environment is
> chosen, which shouldn't happen that often, and shouldn't happen at all
> on Darwin or BSD. The code as it currently is has even an extra
> condition for NetBSD reverting to "apcs-gnu".
>
> Since these things are largely arbitrary, creating a code that makes
> sense and is simple is hard. But regarding the decision to move the
> default to aapcs, I have to say I also agree.
>

Agree with what though? For bare metal people should be using aapcs? Yeah,
I agree. For that we should just define an ABI for arm-elf and do that.
That said, the default is different between the front end and back end is
different for no reason now and fixing the tests in the back end is much
more complicated than just reverting this. As you said earlier, every other
case just explicitly is recognized.

Since it doesn't seem like there's a reason other than "it seemed like a
nice idea" (which I agree with, just that it's more work than just the
front end change) I'm going to revert this for now and make sure the ABI
definitions are unified between the front and back end. If we decide we
really want to change it then it can be done in both the front end and back
end with the requisite testsuite updates.

-eric


>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141210/b21c3a78/attachment.html>


More information about the cfe-commits mailing list