Bernie Ogden
2014-Jan-09 09:29 UTC
[LLVMdev] [cfe-dev] AArch64 Clang CLI interface proposal
I think that this works (and adds no appreciable driver complexity) provided that we're not expecting to support -mtune. If clang is (one day) going to be able to isel based on one target and optimize based on another then we might find ourselves wanting to change the meaning of -march from 'isel and optimize' to 'isel only'. So Amara's question about -mtune (or more generally, do we want to be able to separate isel and optimization) seems quite relevant. This also only gives one-way compatibility, which seems good enough for selfish clang purposes. As Renato pointed out, that may be the wrong attitude. Should we try to engage the GCC community here?> -----Original Message----- > From: Amara Emerson > Sent: 08 January 2014 14:07 > To: 'Renato Golin'; Bernard Ogden > Cc: Eric Christopher; LLVM Developers Mailing List; Clang Dev > Subject: RE: [cfe-dev] [LLVMdev] AArch64 Clang CLI interface proposal > > Upon thinking about this more, we could go with my original proposal > about > -march accepting both architectures and cores, which would be a > superset of > the values that gcc accepts for -march. > > Once we have that, we can simply alias -mcpu to -march, perhaps taking > precedence over -march in the case where they're both specified. This > should > give enough compatibility with gcc while also using the -march scheme > that > Eric wanted. > > On a related note, clang doesn't seem to do anything with -mtune for > any > target, not even x86. Do we still want to keep it around? We never make > the > distinction in the backend between a core that we do isel for and a > core > that we optimize for. > > Amara
Renato Golin
2014-Jan-09 09:42 UTC
[LLVMdev] [cfe-dev] AArch64 Clang CLI interface proposal
On 9 January 2014 09:29, Bernie Ogden <bogden at arm.com> wrote:> This also only gives one-way compatibility, which seems good enough for > selfish clang purposes. As Renato pointed out, that may be the wrong > attitude. Should we try to engage the GCC community here? >Hi Bernie, I'm doing this internally at Linaro and some ARM GCC folks first, just to see how receptive they are about a formal cooperation. I'm expecting resistance and dismissal, but I'm hoping to be wrong. ;) Would be good if every one could ask their GCC friends to come and play with us, so that ends up as a unison request, not just dust in the wind. cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140109/a9e331c6/attachment.html>
Amara Emerson
2014-Jan-27 10:29 UTC
[LLVMdev] [cfe-dev] AArch64 Clang CLI interface proposal
Ping. Can I assume that we're ok with this interface proposal then? Amara -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140127/49962cbc/attachment.html>
Possibly Parallel Threads
- [LLVMdev] [cfe-dev] AArch64 Clang CLI interface proposal
- [LLVMdev] [cfe-dev] AArch64 Clang CLI interface proposal
- [LLVMdev] AArch64 Clang CLI interface proposal
- [LLVMdev] [cfe-dev] AArch64 Clang CLI interface proposal
- [LLVMdev] [cfe-dev] AArch64 Clang CLI interface proposal