Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add LDC-specific traits for CTFE information about the target machine. #1434

Merged
merged 2 commits into from
Jun 6, 2016

Conversation

JohanEngelen
Copy link
Member

@JohanEngelen JohanEngelen commented Apr 15, 2016

Edit: updated to current state of the PR. (removed __traits(targetFeatures))

This adds the following LDC-specific traits:

__traits(targetCPU) == "broadwell"
__traits(targetHasFeature, "sse2") == bool

Example usage:

import std.stdio;
void main() {
  writeln("CPU = ", __traits(targetCPU));
  writeln("Has 'sse3' = ", __traits(targetHasFeature, "sse3"));
  writeln("Has 'sse4' = ", __traits(targetHasFeature, "sse4"));
  writeln("Has 'sse4.1' = ", __traits(targetHasFeature, "sse4.1"));
}

Outputs on my machine:

❯ ../bin/ldc2 -wi -mcpu=native -run ../../tests/codegen/target_traits.d
CPU = haswell
Has 'sse3' = true
Has 'sse4' = false
Has 'sse4.1' = true

@JohanEngelen
Copy link
Member Author

@9il what do you think?

@9il
Copy link

9il commented Apr 15, 2016

Awesome! Thank you a lot!

@dnadlinger
Copy link
Member

Ping @WalterBright @ibuclaw – what do you think about the API?

@WalterBright
Copy link
Contributor

__traits(targetFeatures) == Tuple("sse", "sse2", ...)
__traits(targetHasFeature, "sse2") == bool

The latter is redundant. We should try to avoid redundant core language features.

@UplinkCoder
Copy link
Contributor

so is hasMember

@JohanEngelen
Copy link
Member Author

The latter is redundant. We should try to avoid redundant core language features.

I left targetHasFeature for convenience.
any!q{a = "sse4.1"}([__traits(targetFeatures)]) is quite ugly I think for functionality that is probably most used out of the three traits.

@ibuclaw
Copy link
Contributor

ibuclaw commented Apr 16, 2016

I can't say that gcc readily provides this information, but it seems reasonable.

@WalterBright
Copy link
Contributor

so is hasMember

True, but we learn from our mistakes rather than repeat them.

is quite ugly

__traits is always ugly. It was intended to be buried in library code. Things that are easily done in the library should not be in the core language.

@JohanEngelen
Copy link
Member Author

I can't say that gcc readily provides this information

Neither does LLVM :(
For -mcpu=native the information is easy to obtain, for -mcpu=haswell it is not...

@ibuclaw
Copy link
Contributor

ibuclaw commented Apr 16, 2016

Neither does LLVM :(

Well at least you have getTargetFeatureString and getTargetCPU exposed to the frontend. ;-)

@JohanEngelen
Copy link
Member Author

OK, I've been able to squeeze the feature info out of LLVM with a small LLVM patch :)
I'll submit that patch to LLVM, and see how that goes over. Then for LLVM<3.9, __traits(targetHasFeature, ...) will only work when either explicitly mentioning the feature on the cmdline, or with cpu=native.

@ibuclaw
Copy link
Contributor

ibuclaw commented Apr 16, 2016

I guess you could cache this information in Target also. That may be the best way for me to do it without adding a new gcc target "hook".

@JohanEngelen
Copy link
Member Author

@mleise
Copy link
Contributor

mleise commented Apr 16, 2016

Nice! I hope this makes it into all compilers. There is always the option to define a safe fall-back like "i386" for dmd on x86. targetHasFeature would be the most frequently used trait in the set. The list version is really only good for "compiled with " output ... unless someone writes a nice wrapper.

@ibuclaw Maybe checking the implementation of this helps:

gcc -march=native -dM -E - < /dev/null | egrep "MMX|SSE|AVX" | sort
#define __AVX__ 1
#define __AVX2__ 1
#define __MMX__ 1
#define __SSE__ 1
…

@ibuclaw
Copy link
Contributor

ibuclaw commented Apr 16, 2016

@mleise - I'm aware of how gcc generates macros, gdc uses the same mechanism for generating pre-defined version conditions. ;-)

All I said was that there is no "ready to use" way of getting the information.

@JohanEngelen JohanEngelen force-pushed the target_traits branch 2 times, most recently from e81cefd to 9a644a6 Compare April 23, 2016 10:43
@JohanEngelen
Copy link
Member Author

I removed __traits(targetFeatures) as this list is not obtainable without hacking LLVM. __traits(targetHasFeature) is more useful and this can be obtained from LLVM with some effort.
Updated the PR.

@JohanEngelen JohanEngelen changed the title [WIP] Add LDC-specific traits for CTFE information about the target machine. Add LDC-specific traits for CTFE information about the target machine. Apr 23, 2016
@JohanEngelen JohanEngelen force-pushed the target_traits branch 2 times, most recently from 9737024 to 34e2896 Compare April 23, 2016 11:56
@JohanEngelen
Copy link
Member Author

For LLVM version < 3.7, hasTargetFeature will always return the safe false default. I don't know how to obtain the necessary information with LLVM < 3.7.

@dnadlinger
Copy link
Member

We might as well just raise the minimum requirement to 3.7 at some point…

@JohanEngelen
Copy link
Member Author

Ping! :)

@9il
Copy link

9il commented May 10, 2016

LGTM

This would be very helpful for Mir's BLAS Micro Kernel parameter estimation. LDC generates (see gist) efficient micro kernel code, and #1472 will allow to optimize it even more :-)

redstar added a commit to redstar/dmd that referenced this pull request May 12, 2016
One theme at DConf was the unification of the frontends.
("One frontend to rule them all")
One source of differences in the frontend are compiler-specific
extensions. An easy way to support this is the addition of hooks.
An application may (or may not) use these hooks for additional
processing.

This hook was inspired by a current PR (ldc-developers/ldc#1434).
LDC-specific pragmas could be realized with the same approach.
redstar added a commit to redstar/dmd that referenced this pull request May 12, 2016
One theme at DConf was the unification of the frontends.
("One frontend to rule them all")
One source of differences in the frontend are compiler-specific
extensions. An easy way to support this is the addition of hooks.
An application may (or may not) use these hooks for additional
processing.

This hook was inspired by a current PR (ldc-developers/ldc#1434).
LDC-specific pragmas could be realized with the same approach.
redstar added a commit to redstar/dmd that referenced this pull request May 12, 2016
One theme at DConf was the unification of the frontends.
("One frontend to rule them all")
One source of differences in the frontend are compiler-specific
extensions. An easy way to support this is the addition of hooks.
An application may (or may not) use these hooks for additional
processing.

This hook was inspired by a current PR (ldc-developers/ldc#1434).
LDC-specific pragmas could be realized with the same approach.
redstar added a commit to redstar/dmd that referenced this pull request May 12, 2016
One theme at DConf was the unification of the frontends.
("One frontend to rule them all")
One source of differences in the frontend are compiler-specific
extensions. An easy way to support this is the addition of hooks.
An application may (or may not) use these hooks for additional
processing.

This hook was inspired by a current PR (ldc-developers/ldc#1434).
LDC-specific pragmas could be realized with the same approach.
redstar added a commit to redstar/dmd that referenced this pull request May 12, 2016
One theme at DConf was the unification of the frontends.
("One frontend to rule them all")
One source of differences in the frontend are compiler-specific
extensions. An easy way to support this is the addition of hooks.
An application may (or may not) use these hooks for additional
processing.

This hook was inspired by a current PR (ldc-developers/ldc#1434).
LDC-specific pragmas could be realized with the same approach.
@JohanEngelen
Copy link
Member Author

@redstar Can I merge this? The "hook" is the same as #5771 so it is easily modified once that is merged.

@JohanEngelen JohanEngelen force-pushed the target_traits branch 3 times, most recently from 59e9b21 to a6bfe12 Compare June 6, 2016 08:55
__traits(targetCPU) == "broadwell"
__traits(targetHasFeature, "sse2") == bool
@JohanEngelen
Copy link
Member Author

Will merge when green.

@JohanEngelen JohanEngelen merged commit d9b012b into ldc-developers:master Jun 6, 2016
@JohanEngelen JohanEngelen deleted the target_traits branch June 6, 2016 18:15
@JohanEngelen
Copy link
Member Author

@9il Can you update us on how you are using this in your code? :)

@9il
Copy link

9il commented Jun 6, 2016

Will do with BLAS release :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants