This is an archive of the discontinued LLVM Phabricator instance.

MIPS: Triple::setArch as R6 if MipsSubArch_r6
ClosedPublic

Authored by wzssyqa on Sep 26 2021, 8:52 PM.

Details

Reviewers
atanasyan
MaskRay
Summary

Currently,

clang -target mipsisa64r6-linux-gnu -mabi=32

will generate a r2 32bit object instead expected r6 one.

The reason is that for some R6 triples, the ArchName and ArchTypeName are different:

ArchTypeName has only 4 choice: mips, mipsel, mips64, mips64el, 
ArchName may be something like mipsisa{32,64}r6{,el}

Diff Detail

Event Timeline

wzssyqa created this revision.Sep 26 2021, 8:52 PM
wzssyqa requested review of this revision.Sep 26 2021, 8:52 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 26 2021, 8:52 PM

If we construct T = Triple("mipsisa64r6el-unknown-linux-gnuabi64") what is result of the T.getArchName() call (without your patch)? If getArchName() returns mipsisa64r6el we need to investigate what is the reason for redundant setArch() call somewhere in the clang driver code. If getArchName() does not return mipsisa64r6el we need to fix triple parsing. One more question - why other targets which has "sub architectures" does not need to extend the Triple::setArch method?

wzssyqa added a comment.EditedSep 27 2021, 8:07 PM

If we construct T = Triple("mipsisa64r6el-unknown-linux-gnuabi64") what is result of the T.getArchName() call (without your patch)?

mipsisa64r6el

If getArchName() returns mipsisa64r6el we need to investigate what is the reason for redundant setArch() call somewhere in the clang driver code.

setArch is not call by clang directly, while from:
llvm/lib/Support/Triple.cpp:

Triple::get32BitArchVariant()
Triple::get64BitArchVariant()

If getArchName() does not return mipsisa64r6el we need to fix triple parsing.
One more question - why other targets which has "sub architectures" does not need to extend the Triple::setArch method?

x86_64 has similir problem, while since they they keep compatiable, it is not a big problem:

$ bin/clang -target i686-linux-gnu -march=x86-64-v3 -m32 -c xx.c

For MIPS r6, it is not full compatiable with r2, so the falldown is a problem here.

For ARMv8, they also have simliar bug/feature:

$ bin/clang -target aarch64-linux-gnu -m32 -c xx.c
$ file xx.o
xx.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), not stripped

In this situation, if ARMv8 has a native 32bit mode, they have 2 choice:

armv7-32  /    aarchv8-32

Of course, ARMv8 doesn't have this mode, as I know.

If we construct T = Triple("mipsisa64r6el-unknown-linux-gnuabi64") what is result of the T.getArchName() call (without your patch)? If getArchName() returns mipsisa64r6el we need to investigate what is the reason for redundant setArch() call somewhere in the clang driver code. If getArchName() does not return mipsisa64r6el we need to fix triple parsing. One more question - why other targets which has "sub architectures" does not need to extend the Triple::setArch method?

any idea?

  • This patch needs test cases. Take a look at llvm/unittests/ADT/TripleTest.cpp
  • IMHO the current fix is not the best solution. It solves the problem but looks a bit strange. For example, the following code (unusual but correct) stops working. Without the patch it produces a correct "arm-linux-gnu" target triple.
Triple T("mipsisa32r6-linux-gnu");
T.setArch(Triple::arm);

It's better to modify Triple::setArch() function so it takes two arguments ArchType and SubArchType. The second argument is NoSubARch by default. Then the setArch() passes both arguments to the getArchTypeName(). We need to teach this function to generate architecture's name in accordance with ArchType and SubArchType arguments. In this patch we can do it for MIPS only. @MaskRay - what do you think?

  • This patch needs test cases. Take a look at llvm/unittests/ADT/TripleTest.cpp
  • IMHO the current fix is not the best solution. It solves the problem but looks a bit strange. For example, the following code (unusual but correct) stops working. Without the patch it produces a correct "arm-linux-gnu" target triple.
Triple T("mipsisa32r6-linux-gnu");
T.setArch(Triple::arm);

ohhh. strange code...

It's better to modify Triple::setArch() function so it takes two arguments ArchType and SubArchType. The second argument is NoSubARch by default. Then the setArch() passes both arguments to the getArchTypeName(). We need to teach this function to generate architecture's name in accordance with ArchType and SubArchType arguments. In this patch we can do it for MIPS only. @MaskRay - what do you think?

I don't think modify `getArchTypeName' is a good idea.
I prefer keep TypeName as it, and use ArchName to hold more info.

In fact it is almost same as my first shape of code: Add a new function

getArchName(ArchType Kind)
wzssyqa updated this revision to Diff 379340.Oct 13 2021, 4:47 AM
atanasyan accepted this revision.Oct 18 2021, 12:53 AM

LGTM. But get one more acceptance from any other reviewer before commit.

This revision is now accepted and ready to land.Oct 18 2021, 12:53 AM
arichardson added inline comments.Oct 18 2021, 6:09 AM
llvm/lib/Support/Triple.cpp
1432

Shouldn't all others also preserve the subarch?

wzssyqa marked an inline comment as done.Oct 18 2021, 7:15 AM
wzssyqa added inline comments.
llvm/lib/Support/Triple.cpp
1432

As I know, there are no other architectures need subarch here.
So, I think that it is better to keep it as now.

wzssyqa marked an inline comment as done.Oct 18 2021, 7:15 AM
MaskRay accepted this revision.Oct 19 2021, 11:13 AM

The llvm/lib/Support/Triple.cpp change LGTM.

For clang -target mipsisa64r6-linux-gnu -mabi=32, what include and library paths do it use? It may be related to clang/lib/Driver/Driver.cpp:computeTargetTriple

This comment was removed by wzssyqa.

The llvm/lib/Support/Triple.cpp change LGTM.

For clang -target mipsisa64r6-linux-gnu -mabi=32, what include and library paths do it use? It may be related to clang/lib/Driver/Driver.cpp:computeTargetTriple

Yes. You are right, while it is another bug.
I will fix it.

Do you have commit access?

Do you have commit access?

No. I have no commit access.

atanasyan closed this revision.Oct 21 2021, 5:07 AM

The patch committed at rG302a165