Fix the issue of .o file generated by Flang
with Flags info is 0x0 under RISC-V.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/Driver/ToolChains/Flang.cpp | ||
---|---|---|
112–114 | Why is this even conditional?? |
Why does "flang/test/Driver/target-features.f90" list all RISC-V features? Why not use https://github.com/llvm/llvm-project/blob/main/flang/test/Driver/target-cpu-features.f90 instead?
flang/test/Driver/target-features.f90 | ||
---|---|---|
1 ↗ | (On Diff #504460) | What happens if the RISC-V backend is not available? |
4 ↗ | (On Diff #504460) | This one line will require updating once respective bit of LLVM is updated. Let's avoid that :) |
flang/test/Driver/target-features.f90 | ||
---|---|---|
1 ↗ | (On Diff #504460) | Clang doesn't need a backend to be available to generate IR for that architecture. I would hope Flang is the same. |
flang/test/Driver/target-features.f90 | ||
---|---|---|
1 ↗ | (On Diff #504460) |
This test is not generating LLVM IR. It does, however, specify the target which is then translated into many LLVM-specific flags. Also: clang --target=riscv64-linux-gnu --target=riscv64 -c file2.c error: unable to create target: 'No available targets are compatible with triple "riscv64"' 1 error generated. |
flang/test/Driver/target-features.f90 | ||
---|---|---|
1 ↗ | (On Diff #504460) | Because you're trying to use the backend. Pass --emit-llvm and observe it works. |
Based on everyone's comments, I merged the test into target-cpu-features.f90 and only kept the generic -target-feature. At the same time, I removed the switch (TC.getArch()) and passed the test on x86 and RISC-V 64.
Fix the issue of .o file generated by Flang with Flags info is 0x0 under RISC-V.
TBH, I don't see how this is addressed in this patch. If that's something that this patch is intending to fix, then there should be a regression test added.
flang/test/Driver/code-gen-rv64.f90 | ||
---|---|---|
13 | For those of us less familiar with RISC-V - could you explain what's significant about this line? For example, here it is made clear that with the right triple used, one should see a ret instruction within the main function (_QQmain). In here, I just see a "magic" number :) |
Add REQUIRES in tests
flang/test/Driver/code-gen-rv64.f90 | ||
---|---|---|
13 | You can refer: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/download/v1.0/riscv-abi.pdf 8.1. File Header e_flags section |
flang/test/Driver/target-cpu-features.f90 | ||
---|---|---|
0–1 | Can we split this test so that people who do not build riscv target still have aarch64/x86 targets tested in their workspaces? |
flang/test/Driver/target-cpu-features.f90 | ||
---|---|---|
0–1 | Given that this test relies on -###, I think that REQUIRES can be safely removed (please double check) |
flang/test/Driver/target-cpu-features.f90 | ||
---|---|---|
22–23 | Without REQUIRES line, test will be failed here. Due to this patch has little to do with CPU-feature, I think we can only add code-gen-rv64.f90. How about that? |
flang/test/Driver/code-gen-rv64.f90 | ||
---|---|---|
13 | Thanks - and could you add a note in the test that explains where the "magic" 0x5 comes from? | |
flang/test/Driver/target-cpu-features.f90 | ||
22–23 | This line verifies the driver diagnostics, i.e. it's very different to what other lines test in this file. You can safely move it to a dedicated file, e.g. "target-cpu-features-invalid.f90". |
clang/lib/Driver/ToolChains/Flang.cpp | ||
---|---|---|
112–114 | Well RISC-V needs -target-abi so its presence in the list does nothing to say it's properly supported. Nor do I think that's a good argument aside from that. You know every architecture needs to have its target features communicated, so making it conditional is not the right technical approach. Documenting the supported architectures should be done another way; perhaps in the actual documentation that developers/users are going to read, rather than buried in code?.... | |
flang/test/Driver/code-gen-rv64.f90 | ||
8 | Why do we need to go to an object file??? That's terrible practice in Clang tests, and the same should be true of Flang. Test the IR, that is sufficient, and decouples you from the backend. | |
flang/test/Driver/target-cpu-features-invalid.f90 | ||
14 | Don't these come from the backend? Testing them here doesn't seem right... |
flang/test/Driver/code-gen-rv64.f90 | ||
---|---|---|
8 |
I disagree. A compiler driver is responsible for creating a correct backend/LLVM invocation. Is there some other way to verify that the backend invocation is correct? (other then inspecting the generated machine code file). I agree that it is desirable to avoid any architectural details leaking outside of LLVM (into e.g. Clang and/or Flang), but IMHO it's very hard to avoid in practice. |
flang/test/Driver/code-gen-rv64.f90 | ||
---|---|---|
8 | After my test, there is no difference between the LLVM IR generated before and after modification. These tests are also from or similar to those that already exist. So I think we can land this patch first. Then fix these in a new patch. |
LGTM, thanks for contributing!
Please wait for the other reviewers to confirm that they are happy with these changes.
flang/test/Driver/target-cpu-features-invalid.f90 | ||
---|---|---|
14 |
No. Both options are defined in Clang's Options.td: |
flang/test/Driver/target-cpu-features-invalid.f90 | ||
---|---|---|
14 | Then why do they need aarch64-registered-target? Either they're coming from the backend and so you need the backend, or they're coming from the frontend and so you don't need the backend. |
flang/test/Driver/target-cpu-features-invalid.f90 | ||
---|---|---|
14 | Can you clarify what you mean by "they"? I'm referring to driver's command line options, which is what this file is testing.
Again, this is a driver test. The driver integrates the frontend and the backend (as well as other parts). Are you suggesting that this test is moved to LLVM and a dependency on Flang is added to LLVM? |
LG. Please wait for and OK from @jrtc27.
clang/lib/Driver/ToolChains/Flang.cpp | ||
---|---|---|
112–114 | Putting the information in documentation also risks the fact that developers might not see it. Ideally, some portion of the compiler should provide an error if the target or a particular abi is not supported. I think we can discuss this specific issue in a separate patch. |
flang/test/Driver/code-gen-rv64.f90 | ||
---|---|---|
2 | Hi :) |
flang/test/Driver/code-gen-rv64.f90 | ||
---|---|---|
2 | Sorry about that :( line 3: llvm-readelf: command not found There are 3 options:
HTH. |
flang/test/Driver/code-gen-rv64.f90 | ||
---|---|---|
2 | Thanks! I've submitted in https://reviews.llvm.org/D146204. |
flang/test/Driver/code-gen-rv64.f90 | ||
---|---|---|
2 | Hi again! |
flang/test/Driver/code-gen-rv64.f90 | ||
---|---|---|
2 | I noticed this error before, but @DavidSpickett haven't fixed yet. I'll fix it now. |
flang/test/Driver/code-gen-rv64.f90 | ||
---|---|---|
2 | thanks! |
Remove [[fallthrough]] and just list the 3 case consecutively.