{"action":"created","issue":{"url":"https://api.github.com/repos/shibatch/sleef/issues/33","repository_url":"https://api.github.com/repos/shibatch/sleef","labels_url":"https://api.github.com/repos/shibatch/sleef/issues/33/labels{/name}","comments_url":"https://api.github.com/repos/shibatch/sleef/issues/33/comments","events_url":"https://api.github.com/repos/shibatch/sleef/issues/33/events","html_url":"https://github.com/shibatch/sleef/issues/33","id":238036069,"node_id":"MDU6SXNzdWUyMzgwMzYwNjk=","number":33,"title":"Naming of functions for llvm runtime","user":{"login":"shibatch","id":15994775,"node_id":"MDQ6VXNlcjE1OTk0Nzc1","avatar_url":"https://avatars0.githubusercontent.com/u/15994775?v=4","gravatar_id":"","url":"https://api.github.com/users/shibatch","html_url":"https://github.com/shibatch","followers_url":"https://api.github.com/users/shibatch/followers","following_url":"https://api.github.com/users/shibatch/following{/other_user}","gists_url":"https://api.github.com/users/shibatch/gists{/gist_id}","starred_url":"https://api.github.com/users/shibatch/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/shibatch/subscriptions","organizations_url":"https://api.github.com/users/shibatch/orgs","repos_url":"https://api.github.com/users/shibatch/repos","events_url":"https://api.github.com/users/shibatch/events{/privacy}","received_events_url":"https://api.github.com/users/shibatch/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":8,"created_at":"2017-06-23T04:11:26Z","updated_at":"2018-08-15T15:44:08Z","closed_at":null,"author_association":"OWNER","body":"Following the discussion on the issues regarding to migration to new cmake build system, I here created a discussion thread for naming of functions that will be used in llvm runtime.\r\n\r\nhttps://github.com/shibatch/sleef/issues/30\r\nhttps://reviews.llvm.org/D24951\r\n\r\n\r\nRequirements and observation :\r\n\r\n* It is better to follow the specification of the vector ABI.\r\n* glibc already has vectorized math functions, and there should be a way to choose which math library to link.\r\n* Libraries to link should be separately selected for vectorized and non-vectorized math functions.\r\n* Compiler should be able to choose between functions with different accuracy (and possibly additional support for errno, exception, extended input domain, etc.) according to the compiler options. e.g. The compiler chooses the less-accurate version if -ffast-math is specified.\r\n\r\n* Do we need support for vector mask?\r\n* At which level should dispatcher be placed? Is it a good idea to always link to the functions with dispatcher?\r\n* It would be nice if the compiler can collect information as to which features are supported by the specified library from only the exported symbol names. For this, each symbol name should contain the following information.\r\n  * Library ID (SLEEF, glibc, etc.)\r\n  * The corresponding math.h function (sin, atan2f, etc.)\r\n  * Instruction set required to pass the arguments and the return value (SSE2, AVX, etc.)\r\n  * Instruction set required to execute the function (AVX2, SSE4.2+POPCNT, etc.)\r\n  * Vector length\r\n  * Masked or not\r\n  * Whether errno and exception are supported\r\n  * Accuracy and input domain\r\n  * Anything else?\r\n\r\n* Isn't it better to add definition on half and quad FP data type? 80-bit float? double-double?\r\n* OpenCL compatibility?\r\n"},"comment":{"url":"https://api.github.com/repos/shibatch/sleef/issues/comments/413239746","html_url":"https://github.com/shibatch/sleef/issues/33#issuecomment-413239746","issue_url":"https://api.github.com/repos/shibatch/sleef/issues/33","id":413239746,"node_id":"MDEyOklzc3VlQ29tbWVudDQxMzIzOTc0Ng==","user":{"login":"gnzlbg","id":904614,"node_id":"MDQ6VXNlcjkwNDYxNA==","avatar_url":"https://avatars0.githubusercontent.com/u/904614?v=4","gravatar_id":"","url":"https://api.github.com/users/gnzlbg","html_url":"https://github.com/gnzlbg","followers_url":"https://api.github.com/users/gnzlbg/followers","following_url":"https://api.github.com/users/gnzlbg/following{/other_user}","gists_url":"https://api.github.com/users/gnzlbg/gists{/gist_id}","starred_url":"https://api.github.com/users/gnzlbg/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gnzlbg/subscriptions","organizations_url":"https://api.github.com/users/gnzlbg/orgs","repos_url":"https://api.github.com/users/gnzlbg/repos","events_url":"https://api.github.com/users/gnzlbg/events{/privacy}","received_events_url":"https://api.github.com/users/gnzlbg/received_events","type":"User","site_admin":false},"created_at":"2018-08-15T15:44:08Z","updated_at":"2018-08-15T15:44:08Z","author_association":"CONTRIBUTOR","body":"> SLEEF is already pretty complex. I don't think that adding such a feature is a good decision. We can think of so many new features that might be useful, but I don't want to make the library bloated.\r\n\r\n_I think_ that to properly support this feature it would be enough to:\r\n\r\n* remove the `ifdef __AVX__` and friends\r\n* use `__attribute__((target(\"...\"))` on all the functions in the library properly \r\n\r\nThat's pretty much it AFAICT. That would do, even without renaming the dispatchers (people would need to be careful while using them, but that's already kind of the case).\r\n\r\n> I chose the current naming scheme since it would have better compatibility between different architectures.\r\n\r\nThat's a good point that I hadn't thought about. Does this apply to the 128-bit wide functions, or also to the 256/512-bit wide ones (AFAIK only x86 exposes this)? For the 128-bit wide functions writing `_sse` might not make much sense, since all x86 targets that the library support probably have SSE enabled anyways, and that is a very reasonable expectation to have (e.g. most compilers i586 targets have SSE enabled, and i686 ones typically have SSE2 enabled).\r\n\r\n> Please carefully read the reference. They are well defined.\r\n\r\nThe reference said:\r\n\r\n> Vector extension specifier.\r\n>\r\n> * (Nothing) : Dispatcher automatically chooses the fastest available vector extension\r\n\r\nWhere does it say that one needs AVX to call say `__m256d Sleef_sind4_u10(__m256d a);` ?\r\n\r\nI read the reference very quickly as my posts show, so I probably oversaw that, but since calling these functions from a TU with only SSE enabled invokes undefined behavior, this might be something that might be worth repeating in a couple of places to prevent idiots like me from scratching their heads :D "}}
{"actor":{"display_login":"gnzlbg"}}