Mức tối ưu hóa -O3 có nguy hiểm trong g ++ không?

Tôi đã nghe từ nhiều nguồn khác nhau (mặc dù chủ yếu là từ một đồng nghiệp của tôi), rằng việc biên dịch với mức tối ưu hóa -O3trong g ++ bằng cách nào đó là 'nguy hiểm', và nói chung nên tránh, trừ khi được chứng minh là cần thiết.

Điều này có đúng không, và nếu vậy, tại sao? Tôi có nên chỉ gắn bó -O2?

Trong những ngày đầu của gcc (2.8, v.v.) và trong thời đại của egcs, và redhat 2,96 -O3 đôi khi khá lỗi. Nhưng điều này đã hơn một thập kỷ trước và -O3 không khác nhiều so với các mức tối ưu hóa khác (trong lỗi).

Tuy nhiên, nó có xu hướng tiết lộ các trường hợp mọi người dựa vào hành vi không xác định, do phụ thuộc chặt chẽ hơn vào các quy tắc và đặc biệt là các trường hợp góc, của ngôn ngữ.

Như một lưu ý cá nhân, tôi đang chạy phần mềm sản xuất trong lĩnh vực tài chính trong nhiều năm nay với -O3 và chưa gặp phải lỗi nào nếu tôi sử dụng -O2.

Theo nhu cầu phổ biến, đây là một bổ sung:

-O3 và đặc biệt là các cờ bổ sung như -funroll-loop (không được bật bởi -O3) đôi khi có thể dẫn đến nhiều mã máy được tạo. Trong một số trường hợp nhất định (ví dụ: trên một cpu có bộ đệm lệnh L1 đặc biệt nhỏ), điều này có thể gây ra sự chậm lại do tất cả các mã của ví dụ như một số vòng lặp bên trong bây giờ không còn phù hợp với L1I nữa. Nói chung gcc cố gắng khá nhiều để không tạo ra quá nhiều mã, nhưng vì nó thường tối ưu hóa trường hợp chung, điều này có thể xảy ra. Các tùy chọn đặc biệt thiên về điều này (như hủy đăng ký vòng lặp) thường không được bao gồm trong -O3 và được đánh dấu tương ứng trong trang chủ. Vì vậy, nói chung nên sử dụng -O3 để tạo mã nhanh và chỉ quay lại -O2 hoặc -Os (cố gắng tối ưu hóa cho kích thước mã) khi thích hợp (ví dụ: khi trình lược tả chỉ ra L1I bỏ lỡ).

Nếu bạn muốn tối ưu hóa đến mức tối đa, bạn có thể điều chỉnh trong gcc thông qua - thay đổi chi phí liên quan đến tối ưu hóa nhất định. Ngoài ra, lưu ý rằng gcc hiện có khả năng đặt các thuộc tính tại các chức năng kiểm soát cài đặt tối ưu hóa chỉ cho các chức năng này, vì vậy khi bạn thấy bạn gặp vấn đề với -O3 trong một chức năng (hoặc muốn thử các cờ đặc biệt cho chỉ chức năng đó), bạn không cần phải biên dịch toàn bộ tệp hoặc thậm chí toàn bộ dự án với O2.

otoh có vẻ như phải cẩn thận khi sử dụng -Ofast, trong đó nêu rõ:

-Ofast cho phép tối ưu hóa tất cả -O3. Nó cũng cho phép tối ưu hóa không hợp lệ cho tất cả các chương trình tuân thủ tiêu chuẩn.

điều này khiến tôi kết luận rằng -O3 được dự định là tuân thủ đầy đủ các tiêu chuẩn.

Theo kinh nghiệm hơi bị kiểm tra của tôi, việc áp dụng -O3cho toàn bộ chương trình hầu như luôn làm cho nó chậm hơn (so với -O2), vì nó bật vòng lặp tích cực không kiểm soát và nội tuyến khiến chương trình không còn phù hợp với bộ đệm lệnh. Đối với các chương trình lớn hơn, điều này cũng có thể đúng với -O2tương đối -Os!

Mẫu sử dụng dự định -O3là, sau khi định hình chương trình của bạn, bạn áp dụng thủ công nó cho một số ít tệp chứa các vòng lặp quan trọng bên trong thực sự có lợi từ sự đánh đổi không gian tốc độ mạnh mẽ này. Các phiên bản mới hơn của GCC có chế độ tối ưu hóa theo hướng dẫn cấu hình có thể (IIUC) áp dụng có chọn lọc các -O3tối ưu hóa cho các chức năng nóng - tự động hóa hiệu quả quá trình này.

Tùy chọn -O3 bật tối ưu hóa đắt tiền hơn, chẳng hạn như nội tuyến, ngoài tất cả các tối ưu hóa ở mức thấp hơn '-O2' và '-O1'. Mức tối ưu hóa '-O3' có thể tăng tốc độ thực thi kết quả, nhưng cũng có thể tăng kích thước của nó. Trong một số trường hợp khi các tối ưu hóa này không thuận lợi, tùy chọn này thực sự có thể làm cho chương trình chậm hơn.

Vâng, O3 là buggier. Tôi là nhà phát triển trình biên dịch và tôi đã xác định các lỗi gcc rõ ràng và rõ ràng do O3 tạo ra các hướng dẫn lắp ráp SIMD có lỗi khi xây dựng phần mềm của riêng tôi. Từ những gì tôi đã thấy, hầu hết các phần mềm sản xuất đều có O2, điều đó có nghĩa là O3 sẽ ít được kiểm tra và sửa lỗi.

Hãy nghĩ về nó theo cách này: O3 thêm nhiều biến đổi trên đỉnh của O2, trong đó thêm nhiều biến đổi trên đầu O1. Nói theo thống kê, nhiều biến đổi có nghĩa là nhiều lỗi hơn. Điều đó đúng với bất kỳ trình biên dịch nào.

Gần đây tôi gặp một vấn đề sử dụng tối ưu hóa với g++. Vấn đề liên quan đến thẻ PCI, trong đó các thanh ghi (cho lệnh và dữ liệu) đã được gửi lại bởi một địa chỉ bộ nhớ. Trình điều khiển của tôi đã ánh xạ địa chỉ vật lý tới một con trỏ trong ứng dụng và đưa nó vào quy trình được gọi, hoạt động với nó như thế này:

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

Thẻ không hoạt động như mong đợi. Khi tôi nhìn thấy hội đồng tôi hiểu rằng trình biên dịch chỉ ghi someCommand[ the last ]vào pciMemory, bỏ qua tất cả các ghi trước đó.

Tóm lại: hãy chính xác và chú ý với việc tối ưu hóa.