g ++에서 최적화 수준 -O3이 위험합니까?

나는 -O3g ++에서 최적화 수준으로 컴파일하는 것이 어쨌든 '위험한'것이며, 필요하다고 입증되지 않는 한 일반적으로 피해야한다는 다양한 소스 (주로 동료 동료로부터)를 들었습니다 .

이것이 사실입니까? 그렇다면 왜 그렇습니까? 난 그냥 고집해야 -O2합니까?

gcc의 초기 (2.8 등)와 egc의 시대, 그리고 redhat 2.96 -O3은 때때로 꽤 버그가 많았습니다. 그러나 이것은 10 년 전에 이루어졌으며 -O3는 다른 수준의 최적화 (버기)와 크게 다르지 않습니다.

그러나 그것은 언어의 규칙, 특히 모퉁이 경우에 더 엄격하게 의존하기 때문에 사람들이 정의되지 않은 행동에 의존하는 경우를 드러내는 경향이 있습니다.

개인적으로, 저는 -O3을 사용하여 몇 년 동안 금융 부문에서 프로덕션 소프트웨어를 실행하고 있으며 -O2를 사용했을 경우에는 없었던 버그가 발생하지 않았습니다.

인기있는 수요에 따라 여기에 추가 사항이 있습니다.

-O3 및 특히 -funroll-loops (-O3에 의해 활성화되지 않음)와 같은 추가 플래그는 때때로 더 많은 머신 코드를 생성 할 수 있습니다. 특정 상황에서 (예 : 매우 작은 L1 명령어 캐시가있는 CPU에서) 이로 인해 내부 루프의 모든 코드가 더 이상 L1I에 더 이상 맞지 않기 때문에 속도가 느려질 수 있습니다. 일반적으로 gcc는 너무 많은 코드를 생성하지 않으려 고 노력하지만 일반적으로 일반적인 경우를 최적화하기 때문에 발생할 수 있습니다. 루프 언 롤링과 같이 특히 이러한 경향이있는 옵션은 일반적으로 -O3에 포함되지 않으며 맨 페이지에 표시됩니다. 따라서 일반적으로 빠른 코드를 생성하기 위해 -O3을 사용하는 것이 좋으며, 적절한 경우 (예 : 프로파일 러가 L1I가 누락되었음을 나타내는 경우) -O2 또는 -O (코드 크기를 최적화하려고 시도)로만 넘어가는 것이 좋습니다.

최적화를 최대한 활용하려면 특정 최적화와 관련된 비용을 --param을 통해 gcc로 조정할 수 있습니다. 또한 gcc는 이제 이러한 함수에 대해서만 최적화 설정을 제어하는 ​​함수에 속성을 넣을 수있는 기능이 있으므로 한 함수에서 -O3에 문제가 있거나 해당 함수에 대한 특수 플래그를 시도하려는 경우, O2로 전체 파일 또는 전체 프로젝트를 컴파일 할 필요가 없습니다.

-Ofast를 사용할 때는 다음과 같은주의가 필요합니다.

-Ofast는 모든 -O3 최적화를 활성화합니다. 또한 모든 표준 호환 프로그램에 유효하지 않은 최적화를 활성화합니다.

-O3은 표준을 완벽하게 준수한다는 결론을 내 렸습니다.

다소 체크 무늬가있는 경험에서 -O3전체 프로그램에 적용 하면 프로그램이 더 이상 명령 캐시에 더 이상 적합하지 않게하는 적극적인 루프 언 롤링과 인라이닝이 켜지 기 때문에 거의 항상 느려집니다 (에 상대적 -O2). 큰 프로그램의 경우,이 또한 마찬가지가 될 수 -O2를 기준으로 -Os!

의도 된 사용 패턴 -O3 은 프로그램을 프로파일 링 한 후 이러한 공격적인 속도-공간 속도 균형에서 실제로 혜택을받는 중요한 내부 루프가 포함 된 작은 파일에 수동으로 적용하는 것입니다. 최신 버전의 GCC에는 (IIUC) -O3최적화를 핫 기능에 선택적으로 적용 하여이 프로세스를 효과적으로 자동화 할 수있는 프로파일 가이드 최적화 모드가 있습니다 .

-O3 옵션은 하위 레벨 '-O2'및 '-O1'의 모든 최적화 외에도 함수 인라인과 같은 더 비싼 최적화를 켭니다. '-O3'최적화 수준은 결과 실행 파일의 속도를 증가시킬 수 있지만 크기를 늘릴 수도 있습니다. 이러한 최적화가 바람직하지 않은 일부 환경에서는이 옵션으로 인해 실제로 프로그램 속도가 느려질 수 있습니다.

예, O3는 버그가 많습니다. 나는 컴파일러 개발자이며 O3가 자체 소프트웨어를 빌드 할 때 버그가있는 SIMD 어셈블리 지침을 생성하여 발생하는 명확하고 명백한 gcc 버그를 식별했습니다. 내가 본 것에서 대부분의 프로덕션 소프트웨어는 O2와 함께 제공됩니다. 즉, O3은 wrt 테스트 및 버그 수정에 대한 관심을 덜 받게됩니다.

O3는 O2 위에 더 많은 변환을 추가하여 O1 위에 더 많은 변환을 추가합니다. 통계적으로 말하면 더 많은 변환은 더 많은 버그를 의미합니다. 그것은 모든 컴파일러에 해당됩니다.

최근에로 최적화를 사용하는 데 문제가 발생했습니다 g++. 이 문제는 PCI 카드와 관련이 있는데 레지스터 (명령 및 데이터 용)는 메모리 주소로 표시되었습니다. 내 드라이버는 실제 주소를 응용 프로그램 내의 포인터에 매핑하고 호출 된 프로세스에 제공했으며 다음과 같이 작동했습니다.

unsigned int * pciMemory;
askDriverForMapping( & pciMemory );
...
pciMemory[ 0 ] = someCommandIdx;
pciMemory[ 0 ] = someCommandLength;
for ( int i = 0; i < sizeof( someCommand ); i++ )
    pciMemory[ 0 ] = someCommand[ i ];

카드가 예상대로 작동하지 않았습니다. 내가 어셈블리를 보았을 때 나는 컴파일러는 쓴 이해 someCommand[ the last ]에 pciMemory선행하는 모든 쓰기를 생략.

결론 : 최적화를 통해 정확하고 세심한주의를 기울이십시오.