Actually, I'm not sure if that is a bug in libstackunwind, but rather in LLVM. I think that this is the behaviour that GCC has specifically for the eh_frame section. This constraint is not part of the DWARF spec, but eh_frame even though it is similar to debug_frame, is not part of the DWARF spec, it just uses a similar encoding. The change itself looks good, but, please wait for the discussion to complete before committing this.
- rC Clang
- 76,437 Commits
- ·
- Restricted Project
- Restricted Project
- Tue, Feb 19, 8:38 AM
- Subversion
- rCTE Clang Tools Extra
- 4,370 Commits
- ·
- Restricted Project
- Restricted Project
- Restricted Project
- Tue, Feb 19, 6:32 AM
- Subversion
Today
I will need someone to commit this change for me. I do not have permission to commit to the svn repo.
I think you uploaded the clang patch into the llvm review?
r354348
Thanks!
LGTM
Looking good, thanks!
Summary clusters, nodes and edges are retrieved from DenseMap with arbitrary order, which doesn't make result DOT file invalid.
Reverse iteration just exposes test issues.
r354345
This needs more work.
Address @courbet's review notes.
Is it expected that the test output is sensitive to reverse iteration?
It sounds to me more like an issue with the code than with how the test is expressed.
In D58231#1402123, @mkazantsev wrote:The main motivation is unification - I don't want to leave a single thing that is supported for intrinsic guards and not supported for control flow guards. Unswitching has known problems related to exponential code size growth, so I don't want our ability to eliminate guards in loops to depend on its cost model.
Trivial unswitch does not have a problem of exponential code growth.
Basically, what you do here does match what trivial unswitch does.
So in order to rely on unswitch we just need to ensure that this widenable branch thing does fall into a trivial unswitch category.