Sometimes escape analysis, strict aliasing, restrict etc can get the job done, but it's unreliable as hell. I often see hotspots in profiles dereferencing multiple levels of pointers repeatedly, just because of an intermittent function call.
-
-
Replying to @AndresFreundTec
you are describing undefined behavior, const value in a scope can't be changed by a current thread, compile with -fstrict-aliasing
1 reply 0 retweets 0 likes -
Replying to @hankadusikova
But the target of a pointer to a const value can. And while sometimes that's good enough, often it's not really an option. Sometimes escape analysis is sufficient for the compiler to realize an external call won't affect content of a dynamic allocation, but not that often.
2 replies 0 retweets 0 likes -
Replying to @AndresFreundTec
In the language model of C++ it can't and optimizer is allowed to optimized on this premise. Changing the value is an undefined behavior. Let me be clear, I'm not talking about any existing CPU or real computer. I'm talking about C++ model.
1 reply 0 retweets 0 likes -
Replying to @hankadusikova
I think there might be a misunderstanding here. I'm talking about something like int foo(const sometype *p) { if (p->blub < 10) return 0; compute_something(); if (p->blub < 100) return 1; return -1; }
1 reply 0 retweets 0 likes -
Replying to @AndresFreundTec @hankadusikova
AFAIU it isn't UB for p->blub to change across inside of compute_something(). Unless I get the compiler to see that p was allocated const (e.g. const sometype st = ...; foo(&st);) C++ doesn't allow to make the assumption on its own.
1 reply 0 retweets 0 likes -
Replying to @AndresFreundTec @hankadusikova
Even if allocated const the compiler often won't see that (cross TU, too many layers). Also, often it's not actually desirable to have the value be constant for the whole lifetime. It's just for a region of code. Unless I copy the value I cannot make C[++] recognize that.
1 reply 0 retweets 0 likes -
Replying to @AndresFreundTec
Ok, thank you for the example. In this case you can't tell C++ it won't change. The best way is to change your code, so it won't use globals. And if it's member function, you should mark it const.
1 reply 0 retweets 0 likes -
Replying to @hankadusikova
Not using globals doesn't mean the compiler *knows* I'm not. That's kind of my point. Just because I *could* have another pointer the compiler needs to generate slower code. I.e. I don't want less UB, instead I want to add a way to make it UB for pointed to objects to change.
1 reply 0 retweets 0 likes -
Replying to @AndresFreundTec @hankadusikova
(In realistic examples compute_something() would affect code flow and probably take parameters, i.e. wouldn't only be meaningful if it did something with globals. Was too quick to type out the example to think of that.)
2 replies 0 retweets 0 likes
I'd even be happy if @llvmorg and @gnutools were to expose something like LLVM IR's http://llvm.org/docs/LangRef.html#llvm-invariant-start-intrinsic … as builtins. Although I'd prefer something that works across more compilers.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.