They are unused now.
Note: NaCl is still used and is currently expected to be needed until 2022-06
(https://blog.chromium.org/2020/08/changes-to-chrome-app-support-timeline.html).
Paths
| Differential D100981
Delete le32/le64 targets AcceptedPublic Authored by MaskRay on Apr 21 2021, 11:03 AM.
Details
Summary They are unused now. Note: NaCl is still used and is currently expected to be needed until 2022-06
Diff Detail
Event TimelineHerald added subscribers: dexonsmith, jfb, hiraditya, mgorny. · View Herald TranscriptApr 21 2021, 11:03 AM Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptApr 21 2021, 11:03 AM Comment Actions Thanks. I had heard in the past that there were some other folks who had used le32/le64 as a "generic" target (in fact that's why it's named so generically, rather than being called "pnacl" or similar) but I haven't heard of anything recently, and as you can see nobody has upstreamed any support for other OS or target specializations or asked to collaborate on it. Practically speaking even a target that wants fairly generic bitcode would probably want its own triple, so unless this removal captures someone's attention who wants to keep maintaining it, this should be fine to remove. This revision is now accepted and ready to land.Apr 21 2021, 5:15 PM This revision was landed with ongoing or failed builds.Apr 21 2021, 6:44 PM This revision was automatically updated to reflect the committed changes. Comment Actions
I think that was us, the Halide language. Any suggested alternative for us to use now? This does indeed break all our llvm usage. EDIT: We are testing to see if using arm triples with an unknown OS works: https://github.com/halide/Halide/pull/5934 The code this is applied to is very careful to not do anything that depends on the triple, which is why we were using the generic one. Given that, it's possible that any old triple will work for us. Comment Actions Any chance that this could be (temporarily) reverted? This will break literally all Halide compilation; we're working on a fix on our side, but it would be nice to have a few days to be sure we have it right, and I suspect there's no urgency to removing this right now. Comment Actions
Will https://github.com/halide/Halide/pull/5934 take longer? If it does, I can temporarily revert this. Comment Actions
Yeah, the first simple attempt in https://github.com/halide/Halide/pull/5934 doesn't work (many things are broken). Temporarily reverting this would be a huge huge favor to us. This revision is now accepted and ready to land.Apr 22 2021, 10:19 AM Comment Actions Would it make sense for you to to upstream an LLVM target such as le32-halide? (Or perhaps even arm32-halide or some other?) Then you'd actually have more control over your own codegen, datalayout, etc. Comment Actions
Fixed by vitalybuka
Revision Contents
Diff 339440 clang/include/clang/Basic/BuiltinsLe64.def
clang/include/clang/Basic/TargetBuiltins.h
clang/include/clang/module.modulemap
clang/lib/Basic/CMakeLists.txt
clang/lib/Basic/Targets.cpp
clang/lib/Basic/Targets/Le64.h
clang/lib/Basic/Targets/Le64.cpp
clang/lib/Basic/Targets/OSTargets.h
clang/lib/CodeGen/ItaniumCXXABI.cpp
clang/lib/CodeGen/TargetInfo.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/CodeGen/ext-int-cc.c
clang/test/CodeGen/le32-arguments.c
clang/test/CodeGen/le32-libcall-pow.c
clang/test/CodeGen/le32-regparm.c
clang/test/CodeGen/le32-vaarg.c
clang/test/CodeGen/pr18235.c
clang/test/CodeGen/target-data.c
clang/test/CodeGenCXX/member-function-pointers.cpp
clang/test/CodeGenCXX/static-init-pnacl.cpp
clang/test/Driver/le32-toolchain.c
clang/test/Driver/le32-unknown-nacl.cpp
clang/test/Driver/le64-unknown-unknown.cpp
clang/test/Headers/stdarg.cpp
llvm/include/llvm/ADT/Triple.h
llvm/lib/Support/Triple.cpp
llvm/test/CodeGen/Generic/no-target.ll
llvm/unittests/ADT/TripleTest.cpp
llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
|