-
-
Notifications
You must be signed in to change notification settings - Fork 888
Pin sourceBase in HwIntrinsics ByteToNormalizedFloat #1770
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
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1770 +/- ##
==========================================
- Coverage 84.49% 84.49% -0.01%
==========================================
Files 849 849
Lines 37413 37412 -1
Branches 4376 4376
==========================================
- Hits 31612 31611 -1
Misses 4947 4947
Partials 854 854
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch!
|
Isn't it better to use |
Yes, JIT should generate the same machine code for |
|
We can deal with that kind of improvement for V3. I’d like to focus now on simply shipping something so we can finally ditch the legacy and build what we want to. |
As you've already said, this code usually works with LOH memory so pinning should be almost free. My main point was about more 'C#'ish code :) |
|
@JimBobSquarePants codecov here fails with a |
The only thing I can see that might allow us to toggle this is the precision field. We could try updating that in the repo codecov.yml file and see what happens? |
Prerequisites
Description
This fixes an overlook in #1398 (which I was reviewing ...), that exposes a potential memory corruption.
sourcecan point to a managed array here, meaning if we don't ask for pinning explicitly, the GC can move the backing array, invalidating the destination address pointed bysourceBase.In practice this almost never happens since big image arrays are allocated on the LOH today, however I still can imagine an unlucky situation with small images where this causes an error.
AsPointershould be used with care, only in cases when we know the destination reference is part of a pinned, native or stack object.