This is an archive of the discontinued LLVM Phabricator instance.

Add Clang support for remaining integer divide and permute instructions from ISA 2.06
ClosedPublic

Authored by nemanjai on Mar 17 2015, 2:35 PM.

Details

Summary

This patch provides some of the missing instructions from ISA 2.06. Namely the integer divide extended instructions (and associated builtins) are provided. The record-form variants are provided but can be accessed through inline assembly only.
Since these instructions are introduced with ISA 2.06, it is important that they not be emitted for targets that implement an older ISA. Also, since they are exposed in the front end through builtinins, it is important that the front end knows not to emit the intrinsics to the back end if the target does not support them. Therefore, this patch provides the ability to test whether the target is Power 7 and up (and Power 8 and up) and use of the builtins is diagnosed on older CPUs.
This diverges from GCC behaviour of controlling the builtins and instructions with -mpopcntd since that option has very little to do with these instructions/builtins.

Note: in a general case, a newer ISA is a superset of the previous ISA. However, instructions are sometimes removed from the ISA. This raises the question whether emitting instructions/builtins based on "IsPwr7Up", et. al. is the right approach. In my opinion, it is unlikely that something that is added in say ISA 2.06 will be removed any time soon, but I welcome other opinions.

Diff Detail

Repository
rL LLVM

Event Timeline

nemanjai updated this revision to Diff 22123.Mar 17 2015, 2:35 PM
nemanjai retitled this revision from to Add Clang support for remaining integer divide and permute instructions from ISA 2.06.
nemanjai updated this object.
nemanjai edited the test plan for this revision. (Show Details)
nemanjai set the repository for this revision to rL LLVM.
nemanjai added a subscriber: Unknown Object (MLST).
wschmidt edited edge metadata.Mar 18 2015, 2:00 PM

Hi Nemanja,

Just a few comments inline.

lib/Basic/Targets.cpp
1267

These strings should not be capitalized, to maintain consistency. As in the other review, I'm not excited about the name.

I really question whether these should be features. Doesn't that imply that these become things that can be controlled independently as -mattr=+/- for llc? I don't think we want that.

1271

mmm, even if we keep this approach, I'm not sure about the Is64Bit one. Surely these aren't the only built-ins that only work for 64-bit. If you're going to add this it needs to be complete and consistent, which is far more than what you're going for here. My inclination is to leave it out and consider whether a full patch for this is sensible down the road.

lib/CodeGen/CGBuiltin.cpp
6390 ↗(On Diff #22123)

I'd prefer that the conditions you've encoded as features just be tested here, rather than using the feature mechanism, but this is a call for people with more experience with this than me.

nemanjai added inline comments.Mar 18 2015, 7:06 PM
lib/Basic/Targets.cpp
1267

Good point about the capitalization. I just used the same names as the bool variables. I can change this.

Regarding the second point, I was careful not to expose these features outside of the target info. They will not become features that have a corresponding Clang option nor will they give the user any control over turning these on/off. This just provides a string-based query for the data members that I added. Essentially, this is a unified "getter" that provides a name-based query.
All that being said, I do see your point. Everything else in this string->bool map is an actual feature that a user has control over. These new ones deviate from that. I am open to suggestions on how to achieve what we are trying to achieve here (namely, control over exposing builtins for non-optional instructions).

1271

I will investigate whether other 64-bit only builtins provide any diagnostics if used in code that is compiled at 32-bit. Thanks for bringing this up.

lib/CodeGen/CGBuiltin.cpp
6390 ↗(On Diff #22123)

I am certainly not opposed to this. Doing so would negate the need for the "fake features" from above. However, the reason for doing it this way was in anticipation of any future CPU's that are a superset of Power7...
Say we implement 5 builtins that are only available on Power7. Then another 17 that are available on Power8. We then get CPU X which is a superset of both. We would need to track down all the places where we check for the correct CPU. Using this approach puts this check in one place.
However, all this is just to explain why I did it this way. If you (or other interested parties) feel that I shouldn't, I'd be happy to change it.

nemanjai added inline comments.Mar 19 2015, 7:00 AM
lib/Basic/Targets.cpp
1271

OK, as it turns out, this seems to largely be ignored by other targets (and we do not seem to have any builtins implemented that are available on 64-bit only.
I personally feel that diagnosing this is better than just letting the back end crash.
Example from Arm:

$ cat t.c 
void test_clrex() {
  __builtin_arm_clrex();
}
$ clang t.c --target=arm-apple-ios7.0 -c
fatal error: error in backend: Cannot select: intrinsic %llvm.arm.clrex
clang: error: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 3.7.0 (trunk 231831) (llvm/trunk 231828:231843M)
Target: arm-apple-ios7.0
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/t-4a719a.c
clang: note: diagnostic msg: /tmp/t-4a719a.sh
clang: note: diagnostic msg: 

********************

Similar example with this changeset:

$ cat a.c 
long long test_divde(void) {
  return __builtin_divde(74LL, 32LL);
}
$ clang a.c -c --target=powerpc-unknown-unknown -mcpu=pwr7
a.c:2:10: error: This builtin is only available on 64-bit targets
  return __builtin_divde(74LL, 32LL);
         ^
1 error generated.

I personally feel that a diagnostic identifying the problem is more helpful to the user than a message that the back end crashed and suggestion to open a bug report.

hfinkel added inline comments.Mar 23 2015, 1:18 PM
lib/Basic/Targets.cpp
745

We don't need the 'Up' in the names here; I think we can generally assume that newer cores will provide backward compatibility, and only when they don't would we need some kind of HasP8Only feature.

747

Please remove this. We can get at the current pointer size from generic code.

1271

I agree, we should generate an error in the frontend instead of just crashing in the backend.

lib/CodeGen/CGBuiltin.cpp
6390 ↗(On Diff #22123)

I have a weak preference for keeping the cpu -> feature logic localized to the target code, so I think this general scheme is good.

hfinkel added inline comments.Mar 23 2015, 1:20 PM
lib/Basic/Targets.cpp
1267

Also, please keep the existing naming convention for these (lowercase, etc.), and we don't need all of the aliases. How about just adding features for 'isa-2.06', 'isa-2.07', etc.?

nemanjai updated this revision to Diff 22691.Mar 25 2015, 6:54 PM
nemanjai edited edge metadata.

Updated the patch to address the comments and to synchronize the way the builtins are enabled between the front end and back end.

nemanjai added inline comments.Mar 25 2015, 6:58 PM
lib/Basic/Targets.cpp
746

Rather than having the ISA level here, I've opted for the same names in the front end and the back end. If we choose to add group features to the back end for the ISA level, we can revisit doing it here as well.

LGTM with one small change.

lib/CodeGen/CGBuiltin.cpp
6411 ↗(On Diff #22691)

You need to split these conditions so that the bpermd feature only controls BI_ _builtin_bpermd and the extdiv feature only controls BI_ _builtin_div*.

nemanjai added inline comments.Mar 26 2015, 7:20 AM
lib/CodeGen/CGBuiltin.cpp
6411 ↗(On Diff #22691)

Good point! We don't want to suppress the diagnostics for the other when only one is enabled :-). Not sure what I was thinking here. I'll fix it in the committed patch. Or would you like another review for just this (of course, if there are other comments this question is moot)?

hfinkel added inline comments.Mar 26 2015, 7:28 AM
lib/CodeGen/CGBuiltin.cpp
6411 ↗(On Diff #22691)

Please note Richards comments on the HTM commit; these error checks should likely be moved into Sema. So, yes, another review round is probably necessary.

nemanjai added inline comments.Mar 26 2015, 1:57 PM
lib/CodeGen/CGBuiltin.cpp
6411 ↗(On Diff #22691)

OK, I see what is needed. Kit is putting in the stuff for HTM. Rather than us clobbering each other, I'll wait until he has that done and update this review then. I'll also use the same framework for the crypto ones at that time. Thanks Hal.

nemanjai updated this revision to Diff 23354.Apr 7 2015, 11:32 AM

Moved the diagnostics to Sema.

wschmidt accepted this revision.Apr 7 2015, 1:17 PM
wschmidt edited edge metadata.

LGTM.

This revision is now accepted and ready to land.Apr 7 2015, 1:17 PM
nemanjai closed this revision.Apr 9 2015, 5:01 PM

Committed revision 234547.