erichkeane added a comment. > ! In D108643#2965852 <https://reviews.llvm.org/D108643#2965852>, @rjmccall > wrote: > > The choice that high bits are unspecified rather than extended is an > interesting one. Can you speak to that? That's good for +, -, *, &, |, ^, > <<, and narrowing conversions, but bad for ==, <, /, >>, and widening > conversions.
So we chose this for a few reasons: 1- Consistency with struct padding bits. It seemed strange to specify the padding bits here, when the rest of the standards/ABI don't specify padding bits. 2- Flexibility of implementation: Requiring zeroing is a more constraining decision, which limits implementation to having to set these bits. By leaving it unspecified, the implementation is free to zero them out if it feels it is worth-while. I'll note that our backends choose NOT to zero them out when not necessary, since (so I'm told) 'masked' compares are trivial in most processors. 3- Implement-ability on FPGAs: Since this was our motivating example, forcing an FPGA to zero out these bits when dealing with an interaction with a byte-aligned processor would have incredible performance overhead. 4- Ease of implementation: Forcing LLVM to zero out these bits would either mean we had to do quite a bit of work in our CodeGen to zero them out, or modify most of the backends to not zero padding bits in these cases. Since there isn't a particular performance benefit (see #2) we didn't think it would be worth while. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D108643/new/ https://reviews.llvm.org/D108643 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
