Поскольку строгие псевдонимы могут помочь компилятору лучше оптимизировать, C99 представил ключевое слово restrict
, которое можно использовать в качестве квалификатора переменной, если программисты гарантируют, что к ней не будет доступа через указатель на другой тип. Однако приведение типов между разными типами неизбежно по нескольким причинам, и это заставит компилятор предположить, что один указатель не является псевдонимом другого. Таким образом, метод обхода заключается в отключении глобальной строгой оптимизации псевдонимов путем передачи -fno-strict-aliasing
(флаг GCC). Это совершенно бессмысленно, потому что может быть только два указателя, которые не должны быть полностью оптимизированы. Следовательно, почему бы не ввести противоположное ключевое слово restrict
, которое сообщает компилятору, что не предполагается, что эти два указателя указывают на разные адреса. Это чем-то похоже на то, что делает volatile
, и это говорит компилятору, что эта переменная сильно изменилась, поэтому обращайтесь с ними особым образом. Можно ли создать такое ключевое слово?
EDIT: есть способ решить эту проблему. См. яно комментарий ниже.
restrict
отличается. - person Dmitri   schedule 07.09.2016-fno-strict-aliasing
. Я думаю, что отключать глобальную оптимизацию очень жаль. - person Kevin Dong   schedule 07.09.2016restrict
не кодируется? - person chux - Reinstate Monica   schedule 07.09.2016__may_alias__
GCC для решения проблемы. - person Ian Abbott   schedule 07.09.2016#pragma
подойдет? Лучше, чем добавление языка. - person chux - Reinstate Monica   schedule 07.09.2016uintptr_t
для этого? - person Daniel Jour   schedule 07.09.2016(uintptr_t)(void*)
. Проблема возникает вокруг тела списка и двух контрольных узлов, которые объявлены с типомstruct node*
, а неvoid*
. - person Kevin Dong   schedule 07.09.2016union
, а затем использовать соответствующий член этогоunion
в соответствующее время. См. stackoverflow.com/questions/98650/< /а> - person yano   schedule 07.09.2016-fno-strict-aliasing
и получить некоторое повышение производительности. Спасибо еще раз. - person Kevin Dong   schedule 07.09.2016-fno-strict-aliasing
выигрыш в производительности от использования квалификатораrestrict
, когда это возможно (или стоимость его неиспользования), увеличивается, но если код используетrestrict
правильно, диалект-fno-strict-alising
... - person supercat   schedule 08.09.2016