Как обнаружить «строгий псевдоним» во время компиляции? - PullRequest
2 голосов
/ 07 апреля 2009

' Строгое алиасинг ' Оптимизация требует особой осторожности из исходного кода, s.a. используя объединение вместо приведения указателя. Есть ли способ определить с помощью директив препроцессора (# if / else), пытается ли компилятор выполнить такую ​​оптимизацию?

Я бы хотел сохранить старый и подготовленный не под строгим псевдонимом путь кода для процессоров и компиляторов, которым все равно. Кажется, быстрее.

Редактировать: Предопределенные макросы GCC , похоже, не имеет ничего общего с алиасами. Другими словами, меня больше всего интересует gcc 4.x, но также и общее решение (которое, кажется, не существует).

Ответы [ 4 ]

3 голосов
/ 07 апреля 2009

Полностью зависит от реализации - вам нужно проверить документы для вашего конкретного компилятора (ов). И когда вы задаете такие вопросы, полезно указать, какой компилятор (ы) вы используете.

Полупереносимый способ сделать это из вашего Makefile - определить различные цели для псевдонимов и псевдонимов и определить собственный символ препроцессора STRICT_ALIASING (или любой другой) для псевдонимов.

2 голосов
/ 07 апреля 2009
1 голос
/ 07 апреля 2009

Насколько мне известно, нет никаких инструкций препроцессора для обнаружения строгого алиасинга.

Если вы используете gcc "-Wall", то компилятор предупредит вас о коде, который может нарушить правило строгого алиасинга.

-Wstrict-aliasing --- Эта опция активна, только если ‘-fstrict-aliasing’ активный. Он предупреждает о коде, который может нарушить строгие правила алиасинга что компилятор использует для оптимизация. Предупреждение не поймать все случаи, но пытается поймать более распространенные подводные камни. это включены в «-Wall». Это эквивалентно ‘-Wstrict-aliasing = 3’

Если код, над которым вы работаете, критичен, вы можете отключить -fstring-aliasing в gcc. Или, если вы не хотите отключать строгие псевдонимы, я предлагаю посмотреть на вывод asm, чтобы убедиться, что компилятор не выполняет опасных оптимизаций, которые вам не нужны.


В стороне Акауппи сказал в комментариях:

«Restrict» включает строгий псевдоним оптимизации для конкретных указателей.

Ключевое слово restrict не "напрямую включает ... оптимизации", а скорее дает компилятору больше информации, а эта дополнительная информация косвенно помогает компилятору определить, может ли он применять определенные методы оптимизации.

Хорошее объяснение ключевого слова restrict из документации компилятора TSP DI :

Чтобы помочь компилятору определить зависимости памяти, вы можете указать указатель, ссылка или массив с ключевым словом restrict. Ключевое слово restrict спецификатор типа, который можно применять к указателям, ссылкам и массивам. Его использование представляет собой гарантию программиста, что в пределах указателя Объявление объекта, на который указывает объект, может быть доступно только по этому указателю. любой нарушение этой гарантии делает программу неопределенной. Эта практика помогает компилятор оптимизирует определенные разделы кода, потому что наложение информации может быть легко определено.

1 голос
/ 07 апреля 2009

Нет общего решения. Наиболее близким является #ifdef __cplusplus, так как стандартный C ++ позволяет компилятору предполагать, что указатели на разные типы не являются псевдонимами (если они не char *). Это происходит даже в простом сценарии, например:

void (int *foo, float *bar) {
  *foo++;
  *bar = 0; // Can safely be scheduled between the load and store of foo.
}

Следовательно, «строгое алиасинг» на самом деле не является оптимизацией; «терпеть неопределенное поведение» - это пессимизация.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...