llvm dev - Jan 2014 - [LLVMdev] [cfe-dev] AArch64 Clang CLI interface proposal

On 8 January 2014 12:32, Bernard Ogden <Bernard.Ogden at arm.com> wrote:
>  I don't think there's software that *needs* the compatibility, but
it is
> easier for GCC projects to switch to clang if that compatibility is there -
> which I think is why we go for GCC compatibility in the first place?
>
Hi Bernie,

GCC compatibility is always considered to be an important feature of LLVM,
not the *most* important one. We'll never go beyond reason to add GCC
compatibility just because, especially one that is poorly or not at all
documented.

The general rule of thumb is to ask the questions:
 * Do we really need it?
 * Isn't there any other way?
 * Is this sane? Or should the original authors re-write their programs?

There has been some progress on both GCC and LLVM to co-operate, rather
than follow each other blindly, and I can see this as the only future for
both toolchains.

In this specific case, I'd strongly oppose to follow whatever GCC does,
since the Clang driver is already mind bogging. The only reasonable course
of action from here is to open the discussion in the GCC and LLVM community
together (not sure how, but we'll *have* to figure it out), and follow from
there.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140108/9524f8bb/attachment.html>

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

On 8 January 2014 14:06, Amara Emerson <amara.emerson at arm.com> wrote:
> 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.
>
I'm not against such a change, as long as it doesn't make the driver
even
worse.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140108/1e22908e/attachment.html>

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

Hi Renato,

 

Thanks, that's a helpful explanation of the position. I sympathise with your
'co-operation over following' view, though I'm also not sure how.

 

I'm not convinced that having both -mcpu and -march makes the driver any
more mind boggling - I'm sure we could implement something tidier than what
happened for the ARM32 side. But I think Amara's superset proposal would
have a simpler implementation, so let's move on with that for now.

 

Regards,

 

Bernie

 

From: Renato Golin [mailto:renato.golin at linaro.org] 
Sent: 08 January 2014 12:58
To: Bernard Ogden
Cc: Eric Christopher; LLVM Developers Mailing List; Clang Dev; Amara Emerson
Subject: Re: [cfe-dev] [LLVMdev] AArch64 Clang CLI interface proposal

 

On 8 January 2014 12:32, Bernard Ogden <Bernard.Ogden at arm.com> wrote:

I don't think there's software that *needs* the compatibility, but it is
easier for GCC projects to switch to clang if that compatibility is there -
which I think is why we go for GCC compatibility in the first place?

 

Hi Bernie,

 

GCC compatibility is always considered to be an important feature of LLVM,
not the *most* important one. We'll never go beyond reason to add GCC
compatibility just because, especially one that is poorly or not at all
documented.

 

The general rule of thumb is to ask the questions:

 * Do we really need it?

 * Isn't there any other way?

 * Is this sane? Or should the original authors re-write their programs?

 

There has been some progress on both GCC and LLVM to co-operate, rather than
follow each other blindly, and I can see this as the only future for both
toolchains.

 

In this specific case, I'd strongly oppose to follow whatever GCC does,
since the Clang driver is already mind bogging. The only reasonable course
of action from here is to open the discussion in the GCC and LLVM community
together (not sure how, but we'll *have* to figure it out), and follow from
there. 

 

cheers,

--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140109/cf7425fc/attachment.html>