- rL LLVM
- Fri, Sep 22, 12:54 PM
- Subversion
Yesterday
Please address the comment around (uptr) and update the commit message.
Rebased on latest version.
Corrected code style issues in test file.
In D36258#878511, @hfinkel wrote:That's clearly interesting. This change, however, seems like it should be more-or-less a nop. If you're going to fully unroll, why would peeling help? Do you end up with a shorter critical path through the branches if we "peel" first?
In our pass pipeline, we'd end up with loop-unrolling being quite a bit earlier than upstream. This wasn't so much an intentional choice as an accident of history that we really hadn't evaluated up until now. My best guess is that the peeling was accidentally exposing information to other transformations and that the actual unrolling was incidental to the performance swing. Someone on my team is investigating that a bit further to see what actually happened; what I just said was just an educated guess.
Well, this is not a bug, so this patch is not a fix but a workaround for existing FreeBSD/MIPS kernel's issue.
Fix a typo in the test case. Please take a look, thank you.
Fix typo.
- I vaguely remember trying something like this and having some crypto benchmarks produce bad schedules; I'll see if I can remember/find it
- tryPressure seems like the wrong place to me, as it is used in 3 different contexts: (compared with target limits, compared with increase region limits, and the current max). From your description it sounds like we only want this behavior once.
- Do you have a specific example where this helps?
Hi Boris,
In D38167#879065, @ruiu wrote:At least for x86, null bytes are not nop instructions, so it feels like it just happened to work for MIPS but it wasn't really guaranteed. How did you get a gap in .fini section?
Thanks for the review!
Sorry for inappropriate ping, I'll make sure to stick to the policy.
- Removed redundant NameKind:: qualifiers.
At least for x86, null bytes are not nop instructions, so it feels like it just happened to work for MIPS but it wasn't really guaranteed. How did you get a gap in .fini section?
Yeah, the new name makes a lot more sense. LGTM.