This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 09/18/2018 08:11 AM, Marc Glisse wrote:
On Tue, 18 Sep 2018, François Dumont wrote:If your concern is rather that the condition got evaluated which will eventually slow down execution then I need to check generated code. Any good link explaining how to have a clear view on the generated code ?This. For a file like #include <map> void f(); void g(std::map<int,int> const&m){ if(m.count(42)>0)__builtin_unreachable(); f(); } compiled with g++ file.c -O3 -S -fdump-tree-optimized, I get a file.c.228t.optimized that contains quite a lot of code, not just a call to f.
Too bad, and thanks for the tip on how to generate this.
Maybe a 'if __builtin_constant_p(_Condition)' could help if gcc doesn't do it itself already.How would you use that precisely?
I wouldn't, I wasn't totally waken up when I proposed this, it makes no sens.
Even if I think that doing this kind of operation in an assert call is too much I agree that it makes this change invalid.It may be easiest to use a different macro for trivial tests that can go with __builtin_unreachable and for expensive tests that cannot.
I'll see if I need to introduce a macro the day I want to add a __builtin_unreachable.
François
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |