{"action":"created","issue":{"url":"https://api.github.com/repos/dotnet/coreclr/issues/18045","repository_url":"https://api.github.com/repos/dotnet/coreclr","labels_url":"https://api.github.com/repos/dotnet/coreclr/issues/18045/labels{/name}","comments_url":"https://api.github.com/repos/dotnet/coreclr/issues/18045/comments","events_url":"https://api.github.com/repos/dotnet/coreclr/issues/18045/events","html_url":"https://github.com/dotnet/coreclr/issues/18045","id":324475639,"number":18045,"title":"Intel Hardware Intrinsics test framework design deficiences","user":{"login":"4creators","id":801959,"avatar_url":"https://avatars0.githubusercontent.com/u/801959?v=4","gravatar_id":"","url":"https://api.github.com/users/4creators","html_url":"https://github.com/4creators","followers_url":"https://api.github.com/users/4creators/followers","following_url":"https://api.github.com/users/4creators/following{/other_user}","gists_url":"https://api.github.com/users/4creators/gists{/gist_id}","starred_url":"https://api.github.com/users/4creators/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/4creators/subscriptions","organizations_url":"https://api.github.com/users/4creators/orgs","repos_url":"https://api.github.com/users/4creators/repos","events_url":"https://api.github.com/users/4creators/events{/privacy}","received_events_url":"https://api.github.com/users/4creators/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-05-18T16:29:49Z","updated_at":"2018-05-18T16:47:03Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"A while ago we have had a long discussion about the scope of testing which should be done during Intel Hardware Intrinsics development (for details see https://github.com/dotnet/coreclr/pull/15771).\r\n\r\nThere were two proposals put forward:\r\n1. Test as little as possible concentrating on a check if expected assembly instruction is emitted;\r\n2. Test for wider range of values including known problematic ones\r\n\r\nCurrently we use approach from point 1 which IMO opinion is deficient since it led to several missed implementation bugs i.e.:\r\n\r\nhttps://github.com/dotnet/coreclr/issues/17957\r\nhttps://github.com/dotnet/coreclr/issues/18039\r\nhttps://github.com/dotnet/coreclr/issues/18041\r\nhttps://github.com/dotnet/coreclr/issues/18043\r\n\r\nIt seems that using small set of problematic values for each numeric type would solve that problem without need for creating complex test scenarios i.e.:\r\n\r\n1) for integral types: min, max, -1, 0, 1\r\n2) for unsigned integral types: min, max, 1\r\n3) for floating types: +/- infinity, +/- max/min, +/- 0, subnormal\r\n\r\n@AndyAyersMS  @CarolEidt @fiigii @sdmaclea @tannergooding\r\n"},"comment":{"url":"https://api.github.com/repos/dotnet/coreclr/issues/comments/390266003","html_url":"https://github.com/dotnet/coreclr/issues/18045#issuecomment-390266003","issue_url":"https://api.github.com/repos/dotnet/coreclr/issues/18045","id":390266003,"user":{"login":"tannergooding","id":10487869,"avatar_url":"https://avatars3.githubusercontent.com/u/10487869?v=4","gravatar_id":"","url":"https://api.github.com/users/tannergooding","html_url":"https://github.com/tannergooding","followers_url":"https://api.github.com/users/tannergooding/followers","following_url":"https://api.github.com/users/tannergooding/following{/other_user}","gists_url":"https://api.github.com/users/tannergooding/gists{/gist_id}","starred_url":"https://api.github.com/users/tannergooding/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tannergooding/subscriptions","organizations_url":"https://api.github.com/users/tannergooding/orgs","repos_url":"https://api.github.com/users/tannergooding/repos","events_url":"https://api.github.com/users/tannergooding/events{/privacy}","received_events_url":"https://api.github.com/users/tannergooding/received_events","type":"User","site_admin":false},"created_at":"2018-05-18T16:47:03Z","updated_at":"2018-05-18T16:47:03Z","author_association":"MEMBER","body":"> Currently we use approach from point 1 which IMO opinion is deficient since it led to several missed implementation bugs i.e.:\r\n\r\nI don't agree.\r\n\r\n#17957 is a case where the exposed API did not correctly expose the semantics of the underlying hardware instruction. The API needs to be fixed and tests would likely not have caught this as it requires a particular coding convention to hit in the first place (you need to have the JIT sign extend the result, without the code being optimized away).\r\n\r\n#18043 is not related to hardware intrinsics, but is instead related to the existing SIMD intrinsics.\r\n\r\n#18039 is because the are no tests covering that code in the first place.\r\n\r\n#18041 is also because there is no test covering the code. The existing `Sse2\\ConvertToInt32WithTruncation` test is actually calling `ConvertToInt32`\r\n"}}
{"actor":{"display_login":"tannergooding"}}