(A + B + C) ≠ (A + C + B) และการเรียงลำดับคอมไพเลอร์

การเพิ่มจำนวนเต็ม 32 บิตสองตัวอาจทำให้จำนวนเต็มล้น:

uint64_t u64_z = u32_x + u32_y;

การโอเวอร์โฟลว์นี้สามารถหลีกเลี่ยงได้หากหนึ่งในจำนวนเต็ม 32 บิตถูกแคสต์หรือเพิ่มเป็นจำนวนเต็ม 64 บิตก่อน

uint64_t u64_z = u32_x + u64_a + u32_y;

อย่างไรก็ตามหากคอมไพเลอร์ตัดสินใจที่จะจัดลำดับการเพิ่มใหม่:

uint64_t u64_z = u32_x + u32_y + u64_a;

การล้นจำนวนเต็มอาจยังคงเกิดขึ้น

คอมไพเลอร์ได้รับอนุญาตให้ทำการเรียงลำดับใหม่หรือเราสามารถไว้วางใจให้คอมไพเลอร์สังเกตเห็นความไม่สอดคล้องกันของผลลัพธ์และรักษาลำดับนิพจน์ตามที่เป็นอยู่ได้หรือไม่?

หากเครื่องมือเพิ่มประสิทธิภาพทำการจัดลำดับใหม่ดังกล่าวจะยังคงผูกพันกับข้อกำหนด C ดังนั้นการจัดลำดับใหม่จะกลายเป็น:

uint64_t u64_z = (uint64_t)u32_x + (uint64_t)u32_y + u64_a;

เหตุผล:

เริ่มต้นด้วย

uint64_t u64_z = u32_x + u64_a + u32_y;

การเพิ่มจะดำเนินการจากซ้ายไปขวา

รัฐกฎการส่งเสริมจำนวนเต็มว่าในนอกจากนี้เป็นครั้งแรกในการแสดงออกของเดิมได้รับการเลื่อนตำแหน่งให้เป็นu32_x uint64_tนอกจากนี้ที่สองก็จะได้รับการเลื่อนตำแหน่งให้u32_yuint64_t

ดังนั้นเพื่อให้เป็นไปตามข้อกำหนด C ผู้เพิ่มประสิทธิภาพใด ๆ ต้องเลื่อนระดับu32_xและu32_yเป็นค่าที่ไม่ได้ลงนาม 64 บิต นี่เท่ากับการเพิ่มนักแสดง (การปรับให้เหมาะสมจริงไม่ได้ทำที่ระดับ C แต่ฉันใช้รูปแบบ C เพราะนั่นเป็นสัญกรณ์ที่เราเข้าใจ)

คอมไพเลอร์ได้รับอนุญาตให้สั่งซื้อใหม่ภายใต้กฎas ifเท่านั้น นั่นคือหากการเรียงลำดับใหม่จะให้ผลลัพธ์เหมือนกับลำดับที่ระบุไว้เสมอก็จะได้รับอนุญาต มิฉะนั้น (ตามตัวอย่างของคุณ) ไม่ใช่

ตัวอย่างเช่นได้รับนิพจน์ต่อไปนี้

i32big1 - i32big2 + i32small

ซึ่งได้รับการสร้างขึ้นอย่างรอบคอบเพื่อลบค่าสองค่าซึ่งเป็นที่ทราบกันดีว่ามีค่ามาก แต่ใกล้เคียงกันจากนั้นจึงเพิ่มค่าอื่น ๆ เล็กน้อย (เพื่อหลีกเลี่ยงการล้น) คอมไพเลอร์อาจเลือกที่จะเรียงลำดับใหม่เป็น:

(i32small - i32big2) + i32big1

และอาศัยข้อเท็จจริงที่ว่าแพลตฟอร์มเป้าหมายใช้เลขคณิตสองส่วนร่วมกับการตัดรอบเพื่อป้องกันปัญหา (การเรียงลำดับใหม่ดังกล่าวอาจสมเหตุสมผลหากคอมไพเลอร์ถูกกดเพื่อรีจิสเตอร์และมีi32smallในรีจิสเตอร์อยู่แล้ว)

มีกฎ "เสมือน" ใน C, C ++ และ Objective-C: คอมไพลเลอร์สามารถทำอะไรก็ได้ตราบเท่าที่ไม่มีโปรแกรมที่สอดคล้องกันสามารถบอกความแตกต่างได้

ในภาษาเหล่านี้ a + b + c ถูกกำหนดให้เหมือนกับ (a + b) + c หากคุณสามารถบอกความแตกต่างระหว่างสิ่งนี้กับตัวอย่าง a + (b + c) คอมไพลเลอร์จะไม่สามารถเปลี่ยนลำดับได้ หากคุณไม่สามารถบอกความแตกต่างได้แสดงว่าคอมไพเลอร์สามารถเปลี่ยนลำดับได้ฟรี แต่ไม่เป็นไรเพราะคุณไม่สามารถบอกความแตกต่างได้

ในตัวอย่างของคุณด้วย b = 64 บิต a และ c 32 บิตคอมไพเลอร์จะได้รับอนุญาตให้ประเมิน (b + a) + c หรือแม้แต่ (b + c) + a เพราะคุณไม่สามารถบอกความแตกต่างได้ แต่ ไม่ใช่ (a + c) + b เพราะคุณสามารถบอกความแตกต่างได้

กล่าวอีกนัยหนึ่งคอมไพลเลอร์ไม่ได้รับอนุญาตให้ทำสิ่งใด ๆ ที่ทำให้โค้ดของคุณทำงานแตกต่างจากที่ควร ไม่จำเป็นต้องสร้างรหัสที่คุณคิดว่าจะสร้างหรือที่คุณคิดว่าควรสร้างขึ้น แต่รหัสจะให้ผลลัพธ์ที่ตรงกับที่ควร

อ้างอิงจากมาตรฐาน :

[หมายเหตุ: ตัวดำเนินการสามารถจัดกลุ่มใหม่ได้ตามกฎทางคณิตศาสตร์ตามปกติเฉพาะในกรณีที่ตัวดำเนินการเชื่อมโยงกันหรือสับเปลี่ยนเท่านั้นตัวอย่างเช่นในส่วนต่อไปนี้ int a, b;

/∗ ... ∗/
a = a + 32760 + b + 5;

คำสั่งนิพจน์ทำงานเหมือนกับ

a = (((a + 32760) + b) + 5);

เนื่องจากความเชื่อมโยงและความสำคัญของตัวดำเนินการเหล่านี้ ดังนั้นผลลัพธ์ของผลรวม (a + 32760) จะถูกเพิ่มเข้าไปใน b ถัดไปและผลลัพธ์นั้นจะถูกเพิ่มเป็น 5 ซึ่งส่งผลให้ค่าที่กำหนดให้กับ a บนเครื่องที่โอเวอร์โฟลว์ทำให้เกิดข้อยกเว้นและช่วงของค่าที่แสดงได้โดย int คือ [-32768, + 32767] การนำไปใช้ไม่สามารถเขียนนิพจน์นี้ใหม่เป็น

a = ((a + b) + 32765);

เนื่องจากถ้าค่าของ a และ b เป็นตามลำดับ -32754 และ -15 ผลรวม a + b จะทำให้เกิดข้อยกเว้นในขณะที่นิพจน์ดั้งเดิมจะไม่ และไม่สามารถเขียนนิพจน์ใหม่เป็น

a = ((a + 32765) + b);

หรือ

a = (a + (b + 32765));

เนื่องจากค่าของ a และ b อาจเป็น 4 และ -8 หรือ -17 และ 12 ตามลำดับอย่างไรก็ตามในเครื่องที่การล้นไม่ก่อให้เกิดข้อยกเว้นและผลลัพธ์ของการล้นจะย้อนกลับได้คำสั่งนิพจน์ข้างต้นสามารถ ถูกเขียนใหม่โดยการใช้งานด้วยวิธีการใด ๆ ข้างต้นเนื่องจากผลลัพธ์เดียวกันจะเกิดขึ้น - หมายเหตุ]

คอมไพเลอร์ได้รับอนุญาตให้ทำการเรียงลำดับใหม่หรือเราสามารถไว้วางใจให้คอมไพเลอร์สังเกตเห็นความไม่สอดคล้องกันของผลลัพธ์และรักษาลำดับนิพจน์ตามที่เป็นอยู่ได้หรือไม่?

คอมไพลเลอร์สามารถจัดลำดับใหม่ได้ก็ต่อเมื่อให้ผลลัพธ์เหมือนกัน - ที่นี่ตามที่คุณสังเกตเห็นว่าไม่ได้

เป็นไปได้ที่จะเขียนเทมเพลตฟังก์ชันหากคุณต้องการซึ่งจะส่งเสริมอาร์กิวเมนต์ทั้งหมดstd::common_typeก่อนที่จะเพิ่มสิ่งนี้จะปลอดภัยและไม่ต้องพึ่งพาลำดับอาร์กิวเมนต์หรือการคัดเลือกด้วยตนเอง แต่ก็ค่อนข้างยุ่งยาก

ขึ้นอยู่กับความกว้างบิตของunsigned/int.

2 ด้านล่างไม่เหมือนกัน (เมื่อunsigned <= 32บิต) u32_x + u32_yกลายเป็น 0

u64_a = 0; u32_x = 1; u32_y = 0xFFFFFFFF;
uint64_t u64_z = u32_x + u64_a + u32_y;
uint64_t u64_z = u32_x + u32_y + u64_a;  // u32_x + u32_y carry does not add to sum.

พวกมันเหมือนกัน (เมื่อunsigned >= 34บิต) การส่งเสริมจำนวนเต็มทำให้เกิดการ u32_x + u32_yเพิ่มขึ้นที่คณิตศาสตร์ 64 บิต คำสั่งซื้อไม่เกี่ยวข้อง

มันคือ UB (เมื่อunsigned == 33บิต) การส่งเสริมจำนวนเต็มทำให้เกิดการเพิ่มขึ้นในการคำนวณแบบ 33 บิตที่เซ็นชื่อและมีการลงนามมากเกินไปคือ UB

คอมไพเลอร์ได้รับอนุญาตให้ทำการเรียงลำดับใหม่ ... ?

(คณิตศาสตร์ 32 บิต): สั่งซื้อใหม่ใช่ แต่ผลลัพธ์เดียวกันจะต้องเกิดขึ้นดังนั้นไม่ใช่ว่าการสั่งซื้อ OP เสนอใหม่ ด้านล่างนี้เหมือนกัน

// Same
u32_x + u64_a + u32_y;
u64_a + u32_x + u32_y;
u32_x + (uint64_t) u32_y + u64_a;
...

// Same as each other below, but not the same as the 3 above.
uint64_t u64_z = u32_x + u32_y + u64_a;
uint64_t u64_z = u64_a + (u32_x + u32_y);

... เราสามารถไว้วางใจให้พวกเขาสังเกตเห็นความไม่สอดคล้องกันของผลลัพธ์และรักษาลำดับการแสดงออกตามที่เป็นอยู่ได้หรือไม่?

เชื่อว่าใช่ แต่เป้าหมายการเข้ารหัสของ OP นั้นไม่ชัดเจน ควรu32_x + u32_yมีส่วนร่วม? หาก OP ต้องการการสนับสนุนนั้นรหัสควรเป็น

uint64_t u64_z = u64_a + u32_x + u32_y;
uint64_t u64_z = u32_x + u64_a + u32_y;
uint64_t u64_z = u32_x + (u32_y + u64_a);

แต่ไม่

uint64_t u64_z = u32_x + u32_y + u64_a;