- User Since
- Nov 20 2017, 12:14 PM (8 w, 1 d)
Bump, could someone submit this for me?
Fri, Jan 12
Thanks for the quick reviews!
Turns out you can do the easier thing
Switch error message to use decimal format from hex.
Thank you Zach!
Thu, Jan 11
Ping, could someone please submit this for me?
Wed, Jan 10
If you wouldn't mind committing this for me, I'd really appreciate it.
nth time's the charm!
Tue, Jan 9
Updated with my newer, better understanding of the file layout
Mon, Jan 8
Now that I actually understand how the intervals work, I reworked a lot of what I had written. I think it's much clearer now, but I'm sure there's more nits to be had :)
But according to the code, that can't be true. Specifically, I'm looking at llvm::msf::getFpmStreamLayout. If you look at the loop assuming that FpmBlock is 1, then it pushes index 1 as the first FPM block, adds the result of msf::getFpmIntervalLength (which always returns 4096), and pushes that. This means that the second FPM in the sequence is at index 4097, which would mean that there are 4097 blocks in front of it. Unless block at index 4096 is unused, the first interval is in fact 1 block longer.
Fri, Jan 5
Oh hey also, should this go in 6.0?
Thu, Jan 4
I'm assuming you'll want approval from someone else too, but this looks good to me, and is proven to fix my bug.
Makes sense! Thanks for adding a test btw.
Abandoned in favor of D41742.
Yeah, that's the callstack I'm seeing. And I'm all for as many asserts as we can add to guarantee safety.
Just kidding it already does that?
OOOOH That makes so much sense. I was wondering how you could have 2 FPMs at the start but only one every stride after that, but never connected that to this...
In the process of writing this comment, I rewrote it like 8 times whenever I discovered something. So sorry if this reads disjointly :)
This actually took me 3-4 days to track down, but I'll try to explain as clearly as I can :)
Dec 13 2017
Thanks Reid! Would you mind submitting this for me?
Dec 12 2017
llvm::IntegerType::get(getLLVMContext(), 128) -> Builder.getInt128Ty()
Moved implementation to X86_64 specific code, as according to Microsoft docs this function isn't supported on X86 or ARM.