This is an archive of the discontinued LLVM Phabricator instance.

Handle -mlong-calls on Hexagon
ClosedPublic

Authored by kparzysz on Jul 25 2016, 10:02 AM.

Details

Summary

Move long-calls to m_Group, add handling of that option to the Hexagon target.

Diff Detail

Repository
rL LLVM

Event Timeline

kparzysz updated this revision to Diff 65368.Jul 25 2016, 10:02 AM
kparzysz retitled this revision from to Handle -mlong-calls on Hexagon.
kparzysz updated this object.
kparzysz added reviewers: t.p.northover, echristo.
kparzysz set the repository for this revision to rL LLVM.
kparzysz added a subscriber: cfe-commits.
echristo edited edge metadata.Jul 26 2016, 2:22 PM

Why isn't the existing +long-calls handling good enough (other than making it a generic option rather than arm specific)? You don't seem to be using any of the code in Targets.cpp to do anything.

Also a couple of random comments inline on the patch.

-eric

lib/Basic/Targets.cpp
6263–6266

This seems to be overly complex.

6282–6288

This appears to be unrelated?

It likely is sufficient. The code in Targets.cpp adds checking for "long-calls" feature in hasFeature, but it's not explicitly used anywhere. The rest of the changes are mostly to clean up the handling of feature strings.

Go ahead and split out your cleanups into another patch and remove the custom handling in the hexagon target then.

Thanks!

-eric

kparzysz updated this revision to Diff 65919.Jul 28 2016, 6:11 AM
kparzysz edited edge metadata.
kparzysz marked 2 inline comments as done.

Removed the cleanup part.

You haven't removed the custom handling?

-eric

You haven't removed the custom handling?

The one from the driver? If I remove it, it won't be passed to the compiler (and the testcase will fail).

I forgot to move the no-long-calls from the ARM group to the m group, so I will need to post another patch, but I'd like to know what specific changes you are expecting. I think I was wrong in my earlier comment about the pre-existing handling of long-calls, since it only happens in the ARM target.

kparzysz updated this revision to Diff 68416.Aug 17 2016, 1:53 PM

Moving mno_long_calls to m_Group as well.

I'm hoping this is all that's needed: what I understand as "custom handling" is still needed, since this option is only valid for ARM and Hexagon. The Hexagon way of handling target features will be cleaned up in a subsequent patch.

compnerd added inline comments.
include/clang/Driver/Options.td
1383

It seems a bit weird to have target specific descriptions. AFAIK, the behavior is the same on all the targets: it generates branches which have full addressability (ARC, ARM, BlackFin, Epiphany, MIPS, PPC all support this option, probably amongst other architectures). This would easily grow unwieldily if we try to have target specific descriptions. We support at least ARM, MIPS, PPC, and now Hexagon. Why not make the description generic, something like:

Generate branches with extended addressability, usually via indirect jumps.
kparzysz marked an inline comment as done.Aug 23 2016, 5:33 AM
kparzysz added inline comments.
include/clang/Driver/Options.td
1383

The generic description sounds good to me.

At the same time, I tried -mlong-calls and -mno-long-calls on a trivial C procedure and for both MIPS and PPC/PPC64 I got a warning: "argument unused during compilation: '-mlong-calls'". The generated code for both does not change with -mlong-calls or with -mno-long-calls. What kind of support are you talking about?

Here's the code I tried:

void bar();

void foo() {
  bar();
}
$ clang -target powerpc64 -mno-long-calls -S call.c -O2
clang-4.0: warning: argument unused during compilation: '-mno-long-calls'
kparzysz updated this revision to Diff 68973.Aug 23 2016, 5:40 AM
kparzysz updated this object.
kparzysz marked an inline comment as done.

Changed the option description to be nont

compnerd accepted this revision.Aug 29 2016, 5:28 PM
compnerd added a reviewer: compnerd.

That is a bug in the LLVM implementation. The functionality is supported on other (i.e. gcc) compilers.

This revision is now accepted and ready to land.Aug 29 2016, 5:28 PM
kparzysz closed this revision.Aug 30 2016, 7:08 AM