We need to register effective triple before calling getARMFloatABI.
Add missing code when --print-libgcc-file-name is passed.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Kristof and Peter: Is this ok? Everything seems reasonable to me, but I wanted to make sure that you were aware of this, since it is ARM-related. Thanks.
The change looks like an improvement to me. I've got some comments/suggestions although I don't have any strong opinions here.
- It isn't obvious from the context of Driver.cpp why ComputeEffectiveTriple() needs to be called. After a bit of searching I found the call to getArchNameForCompilerRTLib that contained the call to getARMFloatABI. Is is worth moving the call to ComputeEffectiveTriple just before the call to getARMFloatABI()?
- It would be good to add some tests for some more targets such as --target=arm-linux-gnueabihf and --target=arm-linux-gnueabi -mfloat-abi=hard
- It isn't obvious from the context of Driver.cpp why ComputeEffectiveTriple() needs to be called. After a bit of searching I found the call to getArchNameForCompilerRTLib that contained the call to getARMFloatABI. Is is worth moving the call to ComputeEffectiveTriple just before the call to `()?
I was also thinking about that but it seems that ToolChain::getCompilerRT is also being called by many other functions. If we register effective triple right before the call to getARMFloatABI it will replace the origin EffectiveTriple in Toolchain. This may cause some side effects we don't want.
lib/Driver/Driver.cpp | ||
---|---|---|
1311 ↗ | (On Diff #108666) | Is there any reason to not hoist this irrespective of the runtime type? Basically, if we are going to be printing the "libgcc" filename, we compute and register the effective triple before we determine the location. |
lib/Driver/Driver.cpp | ||
---|---|---|
1311 ↗ | (On Diff #108666) | It is not required to register the effective triple before printing libgcc filename. We only need to do so for compiler-rt runtimes. Is there any benefit to hoist this irrespective of the runtime type? |
Right, I realize that it is only needed for the compiler-rt case, but I think it simplifies the flow and makes the behaviour similar across the two branches.
Thanks for adding the extra tests. It seems like getARMFloatABI used to compute its own EffectiveTriple but this was changed to retrieve a cached value D22596, this is a pity for options . With this in mind I think putting the RegisterEffectiveTriple within the scope of OPT_print_libgcc_file_name. I agree with compnerd that hoisting it out of the switch makes the flow of the code easier to read, but no strong opinions. No further comments from me.