Page MenuHomePhabricator

[clang][doc] Clang ARM CPU command line argument reference
AbandonedPublic

Authored by SjoerdMeijer on Apr 21 2020, 7:23 AM.

Details

Summary

Following the discussion about -mtune on the cfe dev list, I thought it would be good to make a start with documenting common command line arguments to target different ARM CPU and architecture combinations. This list is not yet complete, is work in progress, but I have just taken 2 recent M-cores as an example.

Diff Detail

Event Timeline

SjoerdMeijer created this revision.Apr 21 2020, 7:23 AM

One question I can't answer and I think would need wider review, is whether this is type of material (common options for specific CPUs) is suited for the Clang Documentation or whether it would be better hosted by Arm itself, for example on developer.arm.com? I think that a more reference like Arm CPU options like https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html would work better in the Clang documentation.

I think the material is useful, especially for people new to these CPUs.

clang/docs/ClangARMCPUsCLI.rst
27

I think you mean arm-arm-none-eabi for an upstream triple selecting the bare-metal driver?

Hi Peter,
Thanks for reviewing again! I thought these examples to be relevant here, because it shows usage and examples of this tool (i.e. open-source clang/llvm). Additional benefits is that source and documentation is in one place, and it allows others, non-Arm people, to edit and review this document too. But I will take this question to the list, to see what people think about this.

SjoerdMeijer abandoned this revision.Apr 22 2020, 1:59 AM

Fair enough, perhaps the audience is too small here on llvm.org for this and this is too niche. In A-profile we have the same problem, so could the exercise for an A-core here, but can't spend time on that now, so will abandon this.

Fair enough, perhaps the audience is too small here on llvm.org for this and this is too niche. In A-profile we have the same problem, so could the exercise for an A-core here, but can't spend time on that now, so will abandon this.

I would find this extremely valuable in the clang documentation. Not sure why this should be put on developer.arm.com as it is compiler-specific as wel as (sub-)target-specific.

Fair enough, perhaps the audience is too small here on llvm.org for this and this is too niche. In A-profile we have the same problem, so could the exercise for an A-core here, but can't spend time on that now, so will abandon this.

I would find this extremely valuable in the clang documentation. Not sure why this should be put on developer.arm.com as it is compiler-specific as wel as (sub-)target-specific.

To be clear, I also like Peter's suggestion of documenting all -m options as gcc does. There's room for both-and here.

SjoerdMeijer added a comment.EditedApr 22 2020, 12:04 PM

To be completely open about this, I had an offline chat with @psmith and @kristof.beyls about this. The reasoning is that this is probably related to my relatively poor choice of the 2 first cores that I describe here. They are microcontrollers, and Clang/LLVM doesn't provide a full embedded toolchain (linker, libraries, etc.), which is e.g. what we add downstream. So, if you're creating an embedded toolchain, you probably know what you're doing, and this is not one of the first problems that you have.

While I agree with that, I also mentioned that there are many issues orthogonal to this. Yes, we need a full toolchain, but I don't understand how improving things step-by-step can be a bad thing, or why we should wait for another thing to appear first before this becomes more valuable. And yes, also -m option documentation needs to be improved, but again, for me that is orthogonal to this doc change. And what I also mentioned, is that absolutely nothing changes about the whole story here if you take an A-core application processor instead of an M-core, for which the toolchain probably looks simpler.

I agree with all your updates and replies on the cfe dev list. You mentioned "complete overhaul", and yes, I think option handling is inconsistent, undocumented, and so in general quite broken. Problem is that I didn't get a lot of buy in here and on the mailing list. So, I was happy to abandon this as I didn't feel like spending more time on this at this point. But my idea was to step-by-step add more cores to this doc, also A-cores.