[PATCH] D45240: [ARM] Compute a target feature which corresponds to the ARM version.

peter.smith added a comment. In https://reviews.llvm.org/D45240#1267846, @stefson wrote: > hey there, I've run into problems with stripping static-libs on arm when > using llvm/clang-7. Could you imagine this patch being at fault? > > strip: armv7a-unknown-linux-gnueabihf-strip --strip-unneede

[PATCH] D45240: [ARM] Compute a target feature which corresponds to the ARM version.

stefson added a comment. Herald added a reviewer: javed.absar. Herald added subscribers: dexonsmith, chrib. hey there, I've run into problems with stripping static-libs on arm when using llvm/clang-7. Could you imagine this patch being at fault? strip: armv7a-unknown-linux-gnueabihf-strip --st

[PATCH] D45240: [ARM] Compute a target feature which corresponds to the ARM version.

This revision was automatically updated to reflect the committed changes. Closed by commit rL330169: [ARM] Compute a target feature which corresponds to the ARM version. (authored by efriedma, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews.llvm

[PATCH] D45240: [ARM] Compute a target feature which corresponds to the ARM version.

efriedma added a comment. > I take it we still have test cases for the arm <-> thumb transition? "-mthumb" and "-marm" are handled in the driver by rewriting the triple. Repository: rC Clang https://reviews.llvm.org/D45240 ___ cfe-commits mailin

[PATCH] D45240: [ARM] Compute a target feature which corresponds to the ARM version.

efriedma updated this revision to Diff 141393. efriedma added a comment. Add a bunch of tests for various arm arches. Make sure we do something reasonable when we can't figure out any arch at all. Repository: rC Clang https://reviews.llvm.org/D45240 Files: lib/Basic/Targets/ARM.cpp tes

[PATCH] D45240: [ARM] Compute a target feature which corresponds to the ARM version.

fhahn accepted this revision. fhahn added a comment. Thanks for updating it to use the stuff from TargetParser. LGTM, with tests for the cases @joerg mentiond. Comment at: lib/Basic/Targets/ARM.cpp:345 // get default FPU features + llvm::ARM::ArchKind Arch = llvm::ARM::par

[PATCH] D45240: [ARM] Compute a target feature which corresponds to the ARM version.

joerg added a comment. Can you make sure that we handle the older ARM versions correctly as well, i.e. v4, v5 and v6? I take it we still have test cases for the arm <-> thumb transition? That's the one part of the triple logic that is really non-trivial. Repository: rC Clang https://reviews

[PATCH] D45240: [ARM] Compute a target feature which corresponds to the ARM version.

rengolin added a subscriber: joerg. rengolin added a comment. LTO is something I never considered before in the context of the target parser, but I understand the issues are similar to what the build attributes were trying to solve, so adding more info shouldn't make it worse. However, this wil

[PATCH] D45240: [ARM] Compute a target feature which corresponds to the ARM version.

efriedma updated this revision to Diff 141237. efriedma added a comment. Compute arch used passed-in CPU, not the global arch. Repository: rC Clang https://reviews.llvm.org/D45240 Files: lib/Basic/Targets/ARM.cpp test/CodeGen/arm-long-calls.c test/CodeGen/arm-no-movt.c test/CodeGen/a

[PATCH] D45240: [ARM] Compute a target feature which corresponds to the ARM version.

efriedma added inline comments. Comment at: lib/Basic/Targets/ARM.cpp:345 // get default FPU features + llvm::ARM::ArchKind Arch = llvm::ARM::parseArch(getTriple().getArchName()); unsigned FPUKind = llvm::ARM::getDefaultFPU(CPU, Arch); fhahn wrote: > Is th

[PATCH] D45240: [ARM] Compute a target feature which corresponds to the ARM version.

fhahn added inline comments. Comment at: lib/Basic/Targets/ARM.cpp:345 // get default FPU features + llvm::ARM::ArchKind Arch = llvm::ARM::parseArch(getTriple().getArchName()); unsigned FPUKind = llvm::ARM::getDefaultFPU(CPU, Arch); Is there a reason we re

[PATCH] D45240: [ARM] Compute a target feature which corresponds to the ARM version.

efriedma updated this revision to Diff 141078. efriedma added a comment. Fixed to use the arch name as the "feature"; otherwise, we miss relevant features in certain cases. This is taken from ARMAsmParser::parseDirectiveArch. Repository: rC Clang https://reviews.llvm.org/D45240 Files: li

[PATCH] D45240: [ARM] Compute a target feature which corresponds to the ARM version.

fhahn added a comment. We also add thumb-mode to the target features, for a similar reason, allowing mixed Thumb/Arm codegen with LTO. Repository: rC Clang https://reviews.llvm.org/D45240 ___ cfe-commits mailing list cfe-commits@lists.llvm.org h

[PATCH] D45240: [ARM] Compute a target feature which corresponds to the ARM version.

fhahn added a reviewer: rengolin. fhahn added a comment. Thanks for looking into this Eli! Adding the architecture version as target feature looks good to me. Comment at: lib/Basic/Targets/ARM.cpp:342 + // rely on the target triple. + switch (ArchKind) { + case llvm::ARM::A

[PATCH] D45240: [ARM] Compute a target feature which corresponds to the ARM version.

SjoerdMeijer accepted this revision. SjoerdMeijer added a comment. This revision is now accepted and ready to land. Agree, this is a real mess. This change looks good to me. Was only wondering, we are only testing target features +v7 and +v8, but do we now also need to check the others, like +v

[PATCH] D45240: [ARM] Compute a target feature which corresponds to the ARM version.

efriedma created this revision. efriedma added reviewers: compnerd, SjoerdMeijer, fhahn. Herald added subscribers: kristof.beyls, javed.absar, mehdi_amini. Currently, the interaction between the triple, the CPU, and the supported features is a mess: the driver edits the triple to indicate the sup