{"action":"created","issue":{"url":"https://api.github.com/repos/chapel-lang/chapel/issues/11638","repository_url":"https://api.github.com/repos/chapel-lang/chapel","labels_url":"https://api.github.com/repos/chapel-lang/chapel/issues/11638/labels{/name}","comments_url":"https://api.github.com/repos/chapel-lang/chapel/issues/11638/comments","events_url":"https://api.github.com/repos/chapel-lang/chapel/issues/11638/events","html_url":"https://github.com/chapel-lang/chapel/pull/11638","id":380448673,"node_id":"MDExOlB1bGxSZXF1ZXN0MjMwNjQ0MzQw","number":11638,"title":"Normalize arch and use CHPL_HOST_ARCH","user":{"login":"mppf","id":3653132,"node_id":"MDQ6VXNlcjM2NTMxMzI=","avatar_url":"https://avatars3.githubusercontent.com/u/3653132?v=4","gravatar_id":"","url":"https://api.github.com/users/mppf","html_url":"https://github.com/mppf","followers_url":"https://api.github.com/users/mppf/followers","following_url":"https://api.github.com/users/mppf/following{/other_user}","gists_url":"https://api.github.com/users/mppf/gists{/gist_id}","starred_url":"https://api.github.com/users/mppf/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mppf/subscriptions","organizations_url":"https://api.github.com/users/mppf/orgs","repos_url":"https://api.github.com/users/mppf/repos","events_url":"https://api.github.com/users/mppf/events{/privacy}","received_events_url":"https://api.github.com/users/mppf/received_events","type":"User","site_admin":false},"labels":[{"id":195153428,"node_id":"MDU6TGFiZWwxOTUxNTM0Mjg=","url":"https://api.github.com/repos/chapel-lang/chapel/labels/stat:%20Work%20in%20Progress","name":"stat: Work in Progress","color":"c5def5","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":13,"created_at":"2018-11-13T22:16:19Z","updated_at":"2018-11-15T14:43:08Z","closed_at":null,"author_association":"MEMBER","pull_request":{"url":"https://api.github.com/repos/chapel-lang/chapel/pulls/11638","html_url":"https://github.com/chapel-lang/chapel/pull/11638","diff_url":"https://github.com/chapel-lang/chapel/pull/11638.diff","patch_url":"https://github.com/chapel-lang/chapel/pull/11638.patch"},"body":"This PR resolves two related problems:\r\n 1. Compiler builds were not differentiated based on architecture (#11386)\r\n 2. `native` as an architecture is more ambiguous than we would like (#9247)\r\n\r\nThe PR takes the following steps:\r\n * updates chpl_arch.py to generate a third tuple component, normalized architecture\r\n * updates printchplenv to output `CHPL_HOST_ARCH`, including for compiler build paths\r\n * updates compiler build to use include CHPL_HOST_ARCH in bin/ path\r\n * updates setchplenv.* scripts for the new bin/ path\r\n\r\nQuestions for discussion:\r\n * How should we write a disambiguated architecture? I'm advocating for something along the lines of `native-x86_64` for example. A reasonable alternative would be to go directly to `haswell` etc. but these are both less likely to be understood by a user and also might leave out optimization opportunities (I think backend compiler `-march=native` can be more aggressive). Anyway, we could also consider `x86_64-native` or `native@x86_64` or `native(x86_64)` or any number of things.\r\n * What can we call the disambiguated architecture? I called the tuple field `narch` (for \"normalized architecture\") but that's almost certainly not the best name...\r\n * How should we update the `bin` directory path? Right now it makes e.g. `bin/native-x86_64-linux64` but it could be `bin/native-x86_64/linux64` or `bin/linux64-native-x86_64` or use different separators or any number of possibilities. I started with the \"arch\" first because that is what GNU target triples do (https://wiki.osdev.org/Target_Triplet)\r\n * In how much detail should we elaborate on `native` or `none` or `unknown` ? I just used `get_native_machine()` which basically is the same as `uname -p` for now. However, we could consider getting much more detail, either from `/proc/cpuinfo` or from `gcc -march=native -E -v - </dev/null 2>&1`. I personally think simply listing the very general architecture information in these cases is sufficient. Additionally, I'd expect that we could choose to change this behavior in the future without causing too much trouble.\r\n\r\n\r\nSummary of Discussion:\r\n * `x86_64-native` vs `native-x86_64` ? Putting x86 first shows a kind of sub-setting, but putting native first is what the user wrote.\r\n * Even if a specialization is selected we could include the general architecture, e.g. `x86_64-sandybridge`\r\n * `x86_64-none` should shorten to just `x86_64`\r\n * default CHPL_HOST_ARCH should be `none`\r\n\r\n- [x] Compiler build in quickstart, hello world works\r\n- [ ] CHPL_HOST_ARCH defaults to `none`\r\n- [ ] check non-quickstart hello world\r\n- [ ] add CHPL_HOST_ARCH to LLVM install paths\r\n- [ ] get LLVM hello world working\r\n- [ ] update the rest of the setchplenv scripts\r\n- [ ] full local testing\r\n- [ ] test on a Cray\r\n- [ ] make sure LLVM backend still works\r\n- [ ] decide if we want to continue using "},"comment":{"url":"https://api.github.com/repos/chapel-lang/chapel/issues/comments/439063296","html_url":"https://github.com/chapel-lang/chapel/pull/11638#issuecomment-439063296","issue_url":"https://api.github.com/repos/chapel-lang/chapel/issues/11638","id":439063296,"node_id":"MDEyOklzc3VlQ29tbWVudDQzOTA2MzI5Ng==","user":{"login":"mppf","id":3653132,"node_id":"MDQ6VXNlcjM2NTMxMzI=","avatar_url":"https://avatars3.githubusercontent.com/u/3653132?v=4","gravatar_id":"","url":"https://api.github.com/users/mppf","html_url":"https://github.com/mppf","followers_url":"https://api.github.com/users/mppf/followers","following_url":"https://api.github.com/users/mppf/following{/other_user}","gists_url":"https://api.github.com/users/mppf/gists{/gist_id}","starred_url":"https://api.github.com/users/mppf/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mppf/subscriptions","organizations_url":"https://api.github.com/users/mppf/orgs","repos_url":"https://api.github.com/users/mppf/repos","events_url":"https://api.github.com/users/mppf/events{/privacy}","received_events_url":"https://api.github.com/users/mppf/received_events","type":"User","site_admin":false},"created_at":"2018-11-15T14:43:08Z","updated_at":"2018-11-15T14:43:08Z","author_association":"MEMBER","body":"@ronawho - yeah, I think we could independently (from the other choices) decide whether printchplenv would show the additional information. However I'd personally favor having printchplenv show the additional information for the sake of being clear with the user about what was inferred. I think the main use case for `printchplenv` for users is to understand what the settings are, and if this is an important setting that is inferred, that's useful to show. For example, if I set CHPL_TARGET_ARCH=native, I'd be happy to see `printchplenv` show the architecture (e.g. `x86_64`) in addition. I think the challenge there though is how to be clear about which part is inferred and which part is not. Using a different variable is one way to do that. Another way is having a predictable and intuitive way to combine the specified part with the inferred part, which I think `native-x86_64` does a reasonable job of, and `x86_64-native` does less well but would still be acceptable I think."}}
{"actor":{"display_login":"mppf"}}