> My understanding is that int128 shouldn't be sign extended because it is > larger than register size, so I think that is frontend problem.
That's not quite right. The signext/zeroext attributes specify that caller will fully extend the value to the size of the containers (which may span multiple physical registers). When the container is bigger than the type, it allows the backend to omit sign/zero-extension instructions. When the container is the same size as the type, it makes no difference and isn't harmful. For example, i65 should have the signext attribute even though it's bigger than a GPR in order to fill the 128-bit container (two 64-bit GPR's). The frontend is just saying that the caller has to deal with the architectural requirements related to sign/zero-extension. It's the backend that needs to know what these requirements are and deal with them. Without the attributes, the backend will arrange for the callee to deal with them instead. > Second problem, frontend gives zeroext for unsigned int32, it should be > either signext or direct (no extension), so I > think that is frontend problem, not backend. This can be fixed in another > place (CGCall.cpp file, ConstructAttributeList > function) but this is common code, so I think current patch is better > solution for this. This shouldn't be a problem but it is an uncomfortable discrepancy with our _documented_ ABI which says that 32-bit integers are always sign-extended to GPR-sized integers. I put the underbars around 'documented' because the available documentation isn't completely reliable as a statement of how things are actually implemented. I discussed it with Matthew Fortune (one of the current GCC maintainers for Mips) at the time and as far as we could tell, the truth of the matter is that unsigned integers are passed zero extended by the caller in all cases. I also ran a few hundred thousand randomized ABI tests and couldn't produce any failures running mixtures of clang-compiled and gcc-compiled code. > I tracked down these issues to patch: http://reviews.llvm.org/D5961 . Are you trying to solve a particular bug? If so, it would be useful to see a failing executable testcase. http://reviews.llvm.org/D9198 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
